This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: dll base address
----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin-developers@cygwin.com>
Sent: Monday, June 11, 2001 11:47 AM
Subject: Re: dll base address
> >Trivial testcase: build a dll with normal ld witha base address of
> >0x610c0000. When linking against that .dll have that .dll listed
> >before cygwin1.dll in the imports section.
> >
> >Run that program from bash. Watch cpu hit 100%. Run that program
from
> >cmd.exe. Watch it work :].
> >
> ><snip discussion predicated on incorrect cause of problem>
>
> But, marking the DLL as unrelocatable will mean that the DLL will
never
> be able to be relocated even when it will work perfectly well.
The only time that it will work well is when _every_ program run within
that session (following a chain of fork() and spawn() calls) has _no_
conflicting dlls in the same address space. If any .dll collides and is
listed first, then that spawn() or fork() call will fail. We've been
lucky so far because the default for .dlls is usually 0x10000000. I
found out this problem due to a different default in the ld I'm using.
(Which is apparently due to how Ralf built it, not to ld in general).
> I'm not convinced that this is the best solution.
I agree. IMO the best solution is to make all cross-process data
transfer dll base aware. However that may take quite some time. I don't
see that marking cygwin1.dll (which is essentially the kernel for us)
non relocatable will break any existing application code.
In a nutshell we have three options:
1) Make cygwin1.dll handle different base address cross-process
properly.
2) Mark cygwin1.dll non-relocatable until time and techniques to
implement 1) are found.
3) Ignore the issue until 1) occurs.
I'm very happy to hear of other ways around the issue... but I think a
quite, easy and not dirty fix is entirely appropriate. After all the NT
Kernel address space is not relocatable, and we are performing similar
tasks :].
Rob
P.S. I have a workaround for the .dll's I'm building(set a different
base address), so I'm not affected by this, however the problem is still
there.
> cgf
>