This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[RFA] ld.texinfo: clarify auto-import documentation


Given some recent confusion on the cygwin mailing list concerning 
auto-import, I figured it would be a good idea to expand this 
documentation slightly.

Short version: the recently fixed bug where ld silently created buggy 
code when auto-importing multiword variables (arrays, structs) also 
applies to OTHER multiword vars (long longs, etc).  The documentation 
implied that ONLY arrays and structs would trigger the "fix" error 
message;  these changes make it clear that several data types can give 
rise to that behavior.

Okay to apply?

--Chuck
2001-09-21  Charles Wilson  <cwilson@ece.gatech.edu>

	* ld.texinfo(enable-auto-import): clarify 
	the explanation.
Index: ld.texinfo
===================================================================
RCS file: /cvs/src/src/ld/ld.texinfo,v
retrieving revision 1.49
diff -u -r1.49 ld.texinfo
--- ld.texinfo	2001/09/12 15:58:10	1.49
+++ ld.texinfo	2001/09/21 06:42:08
@@ -1738,9 +1738,15 @@
 ultimately given by the sum of two constants (Win32 import tables only 
 allow one).  Instances where this may occur include accesses to member 
 fields of struct variables imported from a DLL, as well as using a 
-constant index into an array variable imported from a DLL.  There are
-several ways to address this difficulty.
+constant index into an array variable imported from a DLL.  Any 
+multiword variable (arrays, structs, long long, etc) may trigger
+this error condition.  However, regardless of the exact data type
+of the offending exported variable, ld will always detect it, issue
+the warning, and exit.
 
+There are several ways to address this difficulty, regardless of the
+data type of the exported variable:
+
 One solution is to force one of the 'constants' to be a variable -- 
 that is, unknown and un-optimizable at compile time.  For arrays, 
 there are two possibilities: a) make the indexee (the array's address) 
@@ -1760,12 +1766,19 @@
    @{ volatile int t=1; extern_array[t] @}
 @end example
 
-For structs, the only option is to make the struct itself variable:
+For structs (and most other multiword data types) the only option 
+is to make the struct (or long long, or ...) itself variable:
 
 @example
 extern struct s extern_struct;
 extern_struct.field --> 
    @{ volatile struct s *t=&extern_struct; t->field @}
+@end example
+
+@example
+extern long long extern_ll;
+extern_ll -->
+  @{ volatile long long * local_ll=&extern_ll; *local_ll=... @}
 @end example
 
 A second method of dealing with this difficulty is to abandon

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]