Serious bug in auto-import
Charles Wilson
cwilson@ece.gatech.edu
Sat Sep 8 23:04:00 GMT 2001
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto-import-test.tar.gz
Type: application/x-gzip
Size: 919 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20010908/f1420904/attachment.bin>
More information about the Binutils
mailing list