Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Fri, 1 Apr 2005 14:55:06 -0500 (EST) From: Igor Pechtchanski Reply-To: cygwin AT cygwin DOT com To: Douglas Merrell cc: cygwin AT cygwin DOT com Subject: Re: Cygwin dll initialization from win32 application In-Reply-To: <424D9F14.7000209@merrell.org> Message-ID: References: <424D9F14 DOT 7000209 AT merrell DOT org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Apr 2005, Douglas Merrell wrote: > On Tue, 11 Mar 2003 15:34:07 -0500, Christopher Faylor wrote: > > On Tue, Mar 11, 2003 at 12:48:15PM -0500, Rich LeGrand wrote: > > > Hi all, > > > This has been discussed before, but I have been unable to find any > > > solutions to this problem. > > > > > > Basically I'm trying to call cygwin functions in the cygwin1.dll > > > from a Windows (msvc) application by calling LoadLibrary() and > > > GetProcAddress(). > > > > > > I can see that the cygwin authors have made provision for this > > > (or what looks like a provision) with dll_dllcrt0 (a non-cygwin > > > initialization function.) But when I call it, it crashes. > > > > This has been broken for some time. So far no one has stepped > > forward to fix the problem in cygwin, so it has remained broken. > > ---------------------------------------------------------------- > I ran into this same problem and investigated a bit. Windows > appears to be loading cygwin1.dll differently depending on whether > it is: > 1) linked into the application and loaded automatically by > the Windows loader at runtime (i.e.- compiled with gcc) > or > 2) loaded dynamically by an application call to LoadLibrary > (i.e.- compiled with MSVC++) > > The only difference in the two loaded modules is one double > word at 0x610d2f4c in the .data section (0x610d2f4c memory > address, or 0x000d194c file offset in cygwin1.dll). > > In case 1) the value at the location in memory is exactly as > it appears in the raw cygwin1.dll file: 0x00000000. > > In case 2) the system appears to have changed the value at > this location during the LoadLibrary call to 0x00000001. > > dll_dllcrt0 checks this hardcoded value (see below) as does > the lower level function dll_crt0_FP11per_process. If the > value is 0x00000000, everything works just fine. If the value > is anything other than 0x00000000 (i.e.- in the case where > the library is dynamically loaded using LoadLibrary), the > application crashes with an AccessViolation. > > ? What is this hardcoded value? > > ? Why is the Windows LoadLibrary function changing the value > at this location? Instead of staring at the assembly code, why not build a debug version of cygwin1.dll and look at the actual source? Or even download one -- IIRC all of the snapshots are still built with debugging info intact. FWIW, the source for dll_dllcrt0 is in the (appropriately named) dll_init.cc in the src/winsup/cygwin directory. The hard-coded location is probably one of the static variables. Another point to note is that dll_dllcrt0 isn't called directly -- it's called from cygwin_attach_dll, which is called from _cygwin_dll_entry (which is basically DllMain). This should be enough to get you started in debugging and fixing this. And remember: with Cygwin, . Information on how to submit patches is at . HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/