Mail Archives: cygwin-developers/2001/06/10/22:05:18
On Mon, Jun 11, 2001 at 11:56:22AM +1000, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <cgf AT redhat DOT com>
>To: <cygwin-developers AT cygwin DOT 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.
Right, and, I use software on a regular basis which injects a DLL into
every executable that runs on the system. I don't know where that DLL
loads now. If it happens to load in the 0x61* range, I'm potentially
out of luck.
>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 :].
Of course, I'm not aware of any way to do this in ld, so this may all
be a moot discussion anyway.
cgf
- Raw text -