From: Charles Wilson <cwilson@ece.gatech.edu>
To: egor duda <binutils@sources.redhat.com>
Cc: cygwin-apps@sources.redhat.com
Subject: Re: --enable-auto-import extension
Date: Fri, 28 Jun 2002 18:08:00 -0000 [thread overview]
Message-ID: <3D1D08A1.9070505@ece.gatech.edu> (raw)
In-Reply-To: <1212929671.20020628141818@logos-m.ru>
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
next prev parent reply other threads:[~2002-06-29 1:08 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 [this message]
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
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=3D1D08A1.9070505@ece.gatech.edu \
--to=cwilson@ece.gatech.edu \
--cc=binutils@sources.redhat.com \
--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).