Re: binutils.README

[Charles Wilson <cwilson at ece dot gatech dot edu>]

The behavior reported, in which "long long" and "unsigned long long" 
variables cannot be auto-imported, is not a bug.  It is correct 
behavior.  Binutils correctly flags these variables with the "<variable> 
can't be auto-imported" message, and exits.

The attached tarball can be used to demonstrate this behavior, and 
inspection of the usedll.o file will reveal lines like this:

--relocations--
00000266 dir32             _dll_global_ll_var
0000026c dir32             _dll_global_ll_var

--disassembly--
  265:   a1 00 00 00 00          mov    0x0,%eax
  26a:   8b 15 04 00 00 00       mov    0x4,%edx

Notice that (a) this long long variable is stored as a multiword 
structure, and (b) accesses to the upper word of that structure use the 
'bad' non-zero-addend addressing modes.

Therefore, long long (and unsigned long long) variables are properly 
considered members of the "problematic" class of non-auto-importable 
variables.  The documentation in ld.info gives a number of mechanisms 
that can be used to work around this problem -- but all require source 
code modification, either in the dll or in the client or both.

The ld.info documentation as well as the binutils.README document 
specifically refer to 'arrays' and 'structs' as problementic data types 
for auto-import.  However, that list is not intended to be complete or 
exhaustive; merely representative.

*That* could be made more clear, I suppose.  'arrays' and 'structs' and 
other multi-word variables...

--Chuck

long_long_example.tar.gz

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/