From: "David A. Cobb" <superbiskit@cox.net>
To: Charles Wilson <cwilson@ece.gatech.edu>
Cc: egor duda <binutils@sources.redhat.com>, cygwin-apps@sources.redhat.com
Subject: Re: --enable-auto-import extension
Date: Sun, 07 Jul 2002 18:20:00 -0000 [thread overview]
Message-ID: <3D28A700.80904@cox.net> (raw)
In-Reply-To: <3D1D08A1.9070505@ece.gatech.edu>
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.
.
next prev parent reply other threads:[~2002-07-07 20:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-28 3:19 egor duda
2002-06-28 18:08 ` Charles Wilson
2002-06-30 23:47 ` egor duda
2002-07-01 14:28 ` Charles Wilson
2002-07-02 8:39 ` egor duda
2002-07-02 9:31 ` Christopher Faylor
2002-07-03 2:21 ` egor duda
2002-07-03 12:05 ` Charles Wilson
2002-07-04 3:43 ` egor duda
2002-08-15 10:49 ` Christopher Faylor
2002-08-15 23:21 ` egor duda
2002-07-07 18:20 ` David A. Cobb [this message]
2002-11-11 18:01 Charles Wilson
2002-11-14 10:07 ` Nick Clifton
2002-11-15 5:35 ` egor duda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D28A700.80904@cox.net \
--to=superbiskit@cox.net \
--cc=binutils@sources.redhat.com \
--cc=cwilson@ece.gatech.edu \
--cc=cygwin-apps@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).