This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Serious bug in auto-import
- To: Charles Wilson <cwilson at ece dot gatech dot edu>
- Subject: Re: Serious bug in auto-import
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- Date: Sun, 09 Sep 2001 02:03:51 -0400
- CC: Paul Sokolovsky <Paul dot Sokolovsky at technologist dot com>,binutils at sources dot redhat dot com
- References: <3B8AFF9F.4020902@ece.gatech.edu> <1823.010909@technologist.com> <3B9AC68A.70307@ece.gatech.edu>
Charles Wilson wrote:
>
> True. I panicked. (At least it was private mail; I hadn't (and still
> have not) made that suggestion onlist.
(of course, since Paul posted that excerpt onlist, my panic is now
archived for the world to see. But that's okay, Paul. :-)
>> Imho, the better idea is to make quick surgery
>> to localize the problem. That's exactly what attached patch does:
> I'm going to test this; assuming it works as advertised (and I have no
> reason to think it will not) I recommend immediate inclusion.
Yep. Tested. ld with Paul's patch accurately detects, prints out a
warning message, and exits-with-error whenever "direct addressing" is
used in the .o file with a DLL auto-imported variable. It doesn't
"interfere" when the client code explicitly requests the import thunk
(e.g. client uses __declspec(dllimport)) -- that continues to work as
normal.
With arrays, this is good (and ld links without complaint):
extern <type> array_var_auto_imported_from_DLL;
<type> p[];
p = array_var_auto_imported_from_DLL;
p[12] = ....
Also, this is good:
extern __declspec(dllimport) <type> array_var_from_DLL;
array_var_from_DLL[12] = ....
This is bad (and Paul's ld detects, warns, and exits):
extern <type> array_var_auto_imported_from_DLL;
array_var_auto_imported_from_DLL[12] = ....
Now, with structs, it's a little tricky. Assume the following definition:
typedef struct {
int a;
int b;
} ST_;
This is bad:
extern ST_ st;
st.a = ...
This is also bad (but is an analogous form to the "array" version that
works)...
extern ST_ st;
ST_ p;
p = st;
p.a = ...
This is good:
extern ST_ st;
ST_ * p;
p = &st;
p->a = ...
Of course, that's almost identical to what happens when you do this
(which is also good, of course):
extern __declspec(dllimport) ST_ st;
st.a = ...
The good news is, Paul's patch will always detect, warn, and fail when
the "bad" forms are used -- because it's triggered by the "bad" assember
instructions directly, regardless of what C code produced it. (That is,
no weird list of special cases.) The only question is, when a user gets
Paul's error message, how will the user know HOW to fix the problem (in
their client code)? *That* requires a long list of special cases in
some documentation somewhere...for extern auto-imported array access do
this, for extern auto-imported struct access do that...
Unless of course:
> THEN we can think about a "real" fix for this array-index problem (if
> possible; it may not be). :-)
I've attached a tar.gz of some test code (arrays, structs) that I used
to verify Paul's patch. Also, I've put a cygwin binary version of
20010909 binutils (with Paul's patch) here:
http://www.neuro.gatech.edu/users/cwilson/cygutils/robert-collins/latest/
Since I built this binutils against a snapshot version of cygwin, you
*may* need to also download cygwin-1.3.2-10.tar.bz2 from the same
location. (Warning: both were built with -g and are unstripped; the
tarballs are 10 and 5 Meg, respectively)
--Chuck
auto-import-test.tar.gz