[RFA] [pei-386] prevent ld (auto-import) from generating broken code

[Charles Wilson]

This patch includes a (slightly) modified version of Paul Sokolovsky's 
fix for this bug, and updates to the ld.texinfo file to explain the new 
behavior.

The bug: accessing, from client code, a complex variable imported from a 
DLL (an array or struct; possibly others) with a constant (nonzero) 
offset leads to incorrect "fixups" --- e.g. a[2] is the same as a[0] if 
array 'a' is imported from a DLL.  s.secondfield is the same as 
s.firstfield if struct 's' is imported from a DLL.

The compiled client code has a nonzero addend, but the windows loader 
can't seem to handle "additional" offsets when doing the dynamic 
loading/relocations.

The fix: Paul's patch identifies these problematic accesses (if they 
exist; seems to be rare), prints out the following message, and aborts. 
(Actually, my modification to Paul's patch merely switches the order of 
the two suggested remedies in this message):

stringtest.o: In function `main':
/usr/src/binutils/tmp/stringtest.c:9: aggregate 'hwstr1' is referenced 
in direct addressing mode with constant offset - auto-import failed. 
Workarounds: a) use a 'volatile' auxilliary variable; b) mark the symbol 
with __declspec(dllimport)
collect2: ld returned 1 exit status

ld.texinfo is updated to provide more information on this bug/message, 
and elaborate on the possible workarounds.

See this thread:

[aida_s@mx12.freecom.ne.jp: A serious bug of "ld --enable-auto-import"]
http://sources.redhat.com/ml/binutils/2001-08/msg00595.html

and this one

Re: Serious bug in auto-import
http://sources.redhat.com/ml/binutils/2001-09/msg00126.html

--chuck