Mail Archives: cygwin-developers/2001/06/10/02:15:12
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin-developers AT sources DOT redhat DOT com>
Sent: Sunday, June 10, 2001 2:40 PM
Subject: Re: dll base address
> On Sat, Jun 09, 2001 at 11:16:51PM +1000, Robert Collins wrote:
> >I haven't fixed the problem I reported with Paul Solovoskys patched
ld,
> >but I have a lead... it seems to be that cygwin1.dll is loaded after
a
> >dll that I was linking to, and that cygwin1.dll is getting relocated
:
> >
> >(gdb) info dll
> >DLL Name Load Address
> >f:/src/ldt/auto-import-sample/dll.dll 610c1000
> >e:/cygwin/bin/cygwin1.dll 02561000
> >e:/winnt/system32/kernel32.dll 77e81000
> >e:/winnt/system32/advapi32.dll 77db1000
> >e:/winnt/system32/rpcrt4.dll 77d41000
> >(gdb) print __cygwin_user_data
> >Cannot access memory at address 0x610933a0
> >
> >As you can see, cygwin1.dll has been loaded at 02561000. It seems to
me
> >that if __cygwin_user_data is a non-relocatble variable, that we
should
> >mark cygwin1.dll as non-relocatable.
> >
> >Thoughts?
>
> It's possible that this is just an artifact of faulty handling by gdb.
> I'm not aware of any reason for cygwin1.dll to be unrelocatable.
>
> If you look at the definition of __cygwin_user_data you'll see that
> there is nothing magic about it.
Do we account for a different base address when spawn()ing and
fork()ing? I haven't looked deep enough to tell, but I can assert that
the trivial test case with Paul's ld works when spawn()ed when the .dll
created has a non-colliding base address.
Rob
> Alternate theories is that there is either something wrong with
gcc/binutils,
> that we are missing something in the way that cygwin1.dll is linked,
or
> that there is something wrong with Paul's patched ld.
>
> cgf
>
- Raw text -