Mail Archives: cygwin-developers/2001/06/10/12:08:31
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?
>
>CF> It's possible that this is just an artifact of faulty handling by gdb.
>CF> I'm not aware of any reason for cygwin1.dll to be unrelocatable.
>
>i believe it isn't. when fhandlers are passed between processes,
>they're just copied as array of bytes. this includes their vtables. as
>long as cygwin1.dll is loaded at equal base addresses, everything's
>fine -- all vtables remain valid after copying. but if cygwin1.dll is
>relocated in exec()ed process, first call to virtual method in
>fhandler cause referencing invalid memory.
>
>i hadn't found a way to access vtable in gcc, so i don't know an
>elegant way to fix this.
Um, yes. cygwin1.dll has always assumed that it will be loaded in the
same location in the parent and the child. I guess you could interpret
that as indicating that it is not relocatable but that is not strictly
true. It is just relying on (undocumented) deterministic behavior of
static DLL loading. Unfortunately, LoadLibrary does not provide
deterministic behavior.
Cygwin goes to great lengths to ensure that cygwin-aware DLLs are loaded
in the same location in parent and child but there is obviously no way
that it can ensure the same thing for itself.
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.
cgf
- Raw text -