Hi!

Currently, --enable-auto-import feature of ld has a limitation of
not allowing importing dll data,  which resides at some offset
from exported symbol. This limitation is derived from limitation of
native win32 loader which can't handle such imports.

There're ways to work around such limitation, by changing code so that
it adds offset at runtime, but it won't work very well in case when
reference is in data segment. For instance, when g++ emits exception handling
information, it puts pointer to vtable+8bytes to data segment. If vtable
is imported from dll, application can't auto-import it, and have no
clean way to work around it.

Clean way to handle such situations (other than convincing
Microsoft to change a loader) is to add some runtime support for
non-zero-offset imports.

The idea is to add a vector of "cygwin internal pseudo-relocation"
entries to executable data section and to perform relocations of
appropriate data manually at program startup.

Attached is a proof-of-concept patch to ld and simple testcase.

If this idea is worthwhile, i think i should add more things to the
patch:
1. Make cygreloc generation conditional via --enable-cygwin-reloc or
something like that.
2. If linker creates at least one cygreloc entry, it should emit
reference to some external symbol, say 'cygwin_process_cygreloc' so
that if object contains non-empty cygreloc vector it'd be
guaranteed that it can't be linked with runtime without cygreloc
support.
3. Make relocations a bit more flexible by adding type and size
(possible 64-bit support?) 

Comments?

egor.            mailto:deo@logos-m.ru icq 5165414 fidonet 2:5020/496.19