Re: ld --auto-imports

[Christopher Faylor <cgf at redhat dot com>]

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.

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.

I know that this is a fruitless email and that now everyone is nodding
their heads saying "Yup.  Cygwin not relocatable." I guess I'm just
sharpening my skills for the inevitable responses that I will probably
be making for the next several years.

Btw, whether it is a bug in Cygwin or not, I'm obviously not going to
release a binary version of binutils for Cygwin which incorporates
behavior that breaks the use of Cygwin.  In case anyone was wondering...

cgf