Re: ld --auto-imports

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <binutils@sources.redhat.com>; <libtool@gnu.org>
Sent: Monday, June 11, 2001 6:11 AM
Subject: Re: ld --auto-imports


> On Sun, Jun 10, 2001 at 08:35:05PM +0300, Paul Sokolovsky wrote:
> >RC> Firstly the feedback. I'm using a pre-compiled version from Ralf
> >RC> habacker. That version (and AFAIK it's a stock build) creates the
.dll
> >RC> base image at 0x610c0000 which collides with the cygwin1.dll. Now
the
> >RC> cygwin1.dll is theoretically relocatable, but we've just found
out that
> >RC> it doesn't like relocating :/. According to MSDN, the default
image base
> >RC> for .dll's should be 0x10000000. Is there any reason your
modified ld
> >RC> couldn't set that as the default base address for .dlls? That
would
> >RC> remove the need to add --base-address=0x10000000 to the link line
in
> >RC> libtool.
>
> Before it makes it into the popular consciousness that "the cygwin DLL
is
> not relocatable", I'd like to point out that this is not strictly
true.
>
> The Cygwin DLL assumes that it will be located in the same place in
both
> the parent and the child when forking or execing.  Cygwin assumes that
> it will be able to allocate space for its heaps at the same location
in
> the parent and the child.
>
> This relies on undocumented, and potentially fragile behavior on
Windows.


It's spawn() that caused the behaviour I saw, and AFAICT will occur with
fork() as well. I've gone into this in more detail in the cygwin list.

And this behaviour _is fragile_: specifically there are two cases that
will break cygwin's assumption every single time.

1) The process calling spawn() has cygwin1.dll able to load at it's
preferred base address. The child process image has a different .dll
listed earlier in it's import table, this will cause the child process's
cygwin1.dll base to be different.
2) The process calling spawn() has cygwin1.dll relocated, and the child
process image loads cygwin1.dll at it's preferred base address.

> However, AFAIK, there is no reason why Cygwin couldn't be located at
any
> base besides 0x61000000 as long as it is loaded into the same location
> in the parent and the child.
>
> If it isn't the fork or exec behavior that is the issue here then this
> may be a bug.  If it is a bug then we can fix the bug.

So for the record:
"To the best of my knowledge Cygwin1.dll is 100% relocatable for any
single process."

However, I'm looking for a way to mark cygwin1.dll as non-relocatable to
prevent this issue occuring at all - does anyone here know the
appropriate flag to ld, or a .def file entry to achieve this?

There's more detail on this in the thread "dll base address" on the
cygwin developers list, if anyone wants the full story :]

Rob