[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ld --auto-imports

From: Robert Collins
Subject: Re: ld --auto-imports
Date: Mon, 11 Jun 2001 16:32:22 +1000

----- Original Message -----
From: "Christopher Faylor" <address@hidden>
To: <address@hidden>; <address@hidden>
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
> >RC> base image at 0x610c0000 which collides with the cygwin1.dll. Now
> >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
> >RC> remove the need to add --base-address=0x10000000 to the link line
> >RC> libtool.
> Before it makes it into the popular consciousness that "the cygwin DLL
> not relocatable", I'd like to point out that this is not strictly
> The Cygwin DLL assumes that it will be located in the same place in
> 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
> the parent and the child.
> This relies on undocumented, and potentially fragile behavior on

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
> 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 :]


reply via email to

[Prev in Thread] Current Thread [Next in Thread]