Mail Archives: cygwin/2005/04/01/14:55:20
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, <http://cygwin.com/acronyms/#PTC>. Information
on how to submit patches is at <http://cygwin.com/contrib.html>.
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/
- Raw text -