Mail Archives: cygwin-developers/2001/06/10/21:18:09
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.
If someone has a patch that applies cleanly to the current CVS sources
and a writeup of how auto-import works, I'd like to revisit it again.
I'm not binutils maintainer, however.
I hope that this is not getting confused with Paul's improvements to
--export-all-symbols. I suggested that I might try his
--export-all-symbols changes in an experimental binutils release but
these are unrelated to his auto-import changes. I have, however, seen
my name mentioned in reference to auto-import as if I was in favor of
it. In fact, I only vaguely remember it, and web searches don't turn up
much in the way of description, unfortunately.
cgf
cgf
- Raw text -