Re: Serious bug in auto-import

[Charles Wilson <cwilson at ece dot gatech dot 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