This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: binutils.README
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/