--enable-auto-import extension

[egor duda]

Hi!

Thursday, 04 July, 2002 Christopher Faylor cgf@redhat.com wrote:

CF> On Wed, Jul 03, 2002 at 12:34:43PM +0400, egor duda wrote:
>>Attached is a patch to add support runtime pseudo-relocations in
>>cygwin once/if binutils with support for them are released.

CF> Is there some reason why this has to be linked into the application and
CF> is not run from the DLL?  It looks like you'd need to get the
CF> _image_base__ variable into the DLL somehow but we should be able to do
CF> that in _cygwin_crt0_common if there is no other way to get this.

We have to make sure that we get application's, not cygwin1.dll's
_image_base__, __RUNTIME_PSEUDO_RELOC_LIST__, and
__RUNTIME_PSEUDO_RELOC_LIST_END__. Actually, part that is linked into
application is doing just this -- gets application's _image_base__,
RPRL and RPRLE and pass them to dll.

Actually, dll's client may be another dll. I haven't tested it yet.
Doess _image_base__ for, say, cygintl.dll get updated when/if cygintl.dll
is rebased at load time?

CF> I think it makes sense to do as little as possible in the library stub
CF> code and as much as possible in the DLL so moving the call to
CF> _pei386_runtime_relocator seems like a good thing.

CF> Btw, could you give a paragraph summary of what this code does?  I
CF> haven't been following the binutils discussion that closely.  Sounds
CF> very interesting though...

There is a problem with auto-import when client has a reference to data
object in dll with some offset. For instance, dll exports _foo_struct
and client code contains 'x = _foo_struct.bar'. In this case compiler
generates a relocation with base symbol _foo_struct and addend equal
to offset of field "bar" in the structure. ld (when doing static
linking) and, say, linux ld.so, can handle such relocations, while
Microsoft's loader can't. So, the only option so far was to change
application code to get rid of relocations with non-zero addends. But
this is not always possible -- such relocations may be generated
implicitly. For instance, c++ exception handling emits a record which
contains a pointer to "type info". Pointer to type info is 'vtable +
8'. If vtable is imported from dll, we can't 'auto-import' this data
reference in client code.

So, to work around this limitation of Microsoft's loader we can add
some runtime support for relocations with non-zero addends. ld
generates a vector of "pseudo-relocations" for each such reference in
client code, and then runtime environment perform necessary fixups at
program startup. Additionally, to make sure that runtime environment
supports such "pseudo-relocations" at link-time, iff at least one such
relocation is generated, it also creates reference to symbol
_pei386_runtime_relocator. In case of linking new dll client with old
runtime we'll get error at link-time -- not some strange effects of
some references in client code are missing needed addends.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19