--enable-auto-import extension

[David A. Cobb]

An (obviously untimely) thought.  Would not this technique offer a 
solution to the deficiency that a Windoze "shared object" (.dll) cannot 
reference symbols in the .EXE that loads it?  It's a thought -- the 
linker(?) [or lib-tool] could generate some sort of standard thunk in 
the DLL identifying "Undefined" symbols which the calling program could 
plug in at runtime [invisibly to the user, of course, as part of the 
dll-load, lib-init processing].  It should not even be horribly slower 
initiating, because it is simply shifting into the application itself 
the same work done by a X-Nix loader that the Win loader can't do.

I'll also second Chuck's WooHoo!

Charles Wilson wrote:

> First: Woo Hoo!  Thanks for looking in to this problem Egor!!
>
> egor duda wrote:
>
>
>> 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.
>
>
>
> But why is this cygwin-specific?  It seems that it's equally 
> applicable to mingw (e.g. native) DLLs, just as mingw's gcc can use 
> the current auto-import feature, even though MSVC can't understand or 
> use it...
>
>
>> Attached is a proof-of-concept patch to ld and simple testcase.
>
>
>
> Tested, and works:
>
> $ ./crtest
> ptr=1125, addend=8
> reloc target=401125
> ptr=112b, addend=4
> reloc target=40112b
> data=111 222 333
>
>
>> If this idea is worthwhile, i think i should add more things to the
>> patch:
>
>
>
> Absolutely.  Of course, it would still need to be *rigorously* tested 
> to insure that
>   a) DLLs built this way could still be linked-to by "regular" code 
> that doesn't violate the current limitations.  (e.g. suppose I as the 
> cygintl-2.dll maintainer built the next cygintl-2.dll using this 
> spiffy new ld.exe; so now, cygintl-2.dll has the extra reloc table.
>
> Q1: will existing code that relied on the OLD cygintl-2.dll (without 
> the additional reloc table) and does NOT try to access 
> data-with-addend, STILL work if I drop in the new DLL?  [e.g. runtime 
> backwards compat]
>
> Q2: Could I relink old code (that again, does NOT try to access 
> data-with-addend) to the new DLL using an OLD ld.exe?  (e.g. an 
> enduser of cygintl-2.dll who hasn't updated their binutils)  [e.g 
> linktime backwards compat]
>
> Q3: Is the new DLL usable by windows tools, provided a suitable import 
> library is generated? (I'm thinking here of mingw folks who build DLLs 
> and implibs for use by others with MSVC -- granted, MSVC can't use 
> auto-import at all, much less your extention.  But the same linker 
> will be used even to build "regular" DLLs...we can't break that.)
>
>
>> 1. Make cygreloc generation conditional via --enable-cygwin-reloc or
>> something like that.
>
>
>
> At first, yes, it does need to be conditional -- and default to OFF, 
> probably...
>
> And, it should probably not be "cygwin" specific.  --enable-data-reloc?
>
>
>> 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.
>
>
>
> Okay, that takes care of "new style" exe accidentally linking at 
> runtime to "old style" DLL.  Still, that leaves compatibility 
> questions about
>   existing "old style" EXE ---> "new style" DLL
>   linking a "new" old style EXE using the old linker ---> against a 
> "new style" DLL
>
> This chunk of code (in pe-dll.c)
>
> +      if (pe_dll_extra_pe_debug)
> +        printf ("creating cygreloc entry for %s (addend=%d)\n",
> +               fixup_name, addend);
> +      b = make_cygreloc_fixup_entry (name, fixup_name, addend, 
> output_bfd);
> +      add_bfd_to_link (b, b->filename, &link_info);
>
> doesn't seem to get called in your example -- but it should, if I 
> understand correctly...What's the deal?
>
> Anyway, because I can't see any "creating cygreloc entry..." debug 
> messages, I'm not quite sure exactly where the cygreloc vector GOES -- 
> into the client .o, or into the DLL.  I had assumed the DLL, but your 
> point #2 above confuses that issue for me...
> (cygreloc --> addend_reloc?)
>
>
>> 3. Make relocations a bit more flexible by adding type and size
>> (possible 64-bit support?) 
>
>
>
> I dunno -- that's a tall order.  This addend-offset problem affects 
> structs and arrays -- which come in all SORTS of specific types with 
> different field orders and sizes.  Also, what about recursive offsets?
>
> bob = a[2].foo.bar[3].baz ?
>
> Granted, fixing 64 bit types (long long), simple arrays, and simple 
> structs will go a LONG way to solving the problem in practical terms 
> -- but until EVERY case is covered, we still need to detect the 
> failure cases and warn at link time (not runtime).
>
>> Comments?
>
>
> Nice work so far, but it'll need LOTS of testing and verification, as 
> you can well imagine.  Unfortunately, my time will be VERY VERY 
> limited over the next six weeks to help with this sort of thing -- or 
> for any cygwin-related stuff.  Thesis Defense approaches...
>
> --Chuck
>
>

-- 
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.
.