Mail Archives: cygwin-developers/2001/06/10/21:47:22
On Mon, Jun 11, 2001 at 11:21:46AM +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:18 AM
>Subject: Re: dll base address
>
>
>> On Mon, Jun 11, 2001 at 10:52:41AM +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 2:08 AM
>> >Subject: Re: dll base address
>> >
>> >
>> >>On Sun, Jun 10, 2001 at 06:56:33PM +0400, egor duda wrote:
>> >>>Sunday, 10 June, 2001 Christopher Faylor cgf AT redhat DOT com wrote:
>> >>>>>As you can see, cygwin1.dll has been loaded at 02561000. It
>seems
>> >to me
>> >>>>>that if __cygwin_user_data is a non-relocatble variable, that we
>should
>> >>>>>mark cygwin1.dll as non-relocatable.
>> >>>>>
>> >>>>>Thoughts?
>> >>>
>> ><snip>
>> >>So, the DLL should be relocatable as long as it is consistently
>being
>> >>relocated to the same location.
>> >>
>> >>There is a lot more than just vtables that would need to be
>addressed
>> >>if we were to fix this.
>> >
>> >So for now, we should mark cygwin1.dll as non-relocatable. How do we
>> >do this for gcc/ld ? MS LINK uses /FIXED, and I couldn't see a .def
>> >instruction for it :[.
>>
>>For now, I think we should maintain the same practice as we have for
>>the last five years, i.e., we do nothing.
>>
>>AFAICT, this is all related to Paul Sokolovsky's auto-import patch to
>>binutils/ld. I do remember Paul talking about his techniques but I
>>can't say for certain that they were actually submitted to the binutils
>>mailing list. If they were submitted it was quite some time ago.
>
>It's not related to the auto-import patch at all. It's purely a
>relocation thing.
>
>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.
I'm not convinced that this is the best solution.
cgf
- Raw text -