[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

[nbowler at draconx dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=25355

--- Comment #7 from Nick Bowler <nbowler at draconx dot ca> ---
(In reply to Nick Clifton from comment #6)
> (In reply to Nick Bowler from comment #5)
> 
> >  - The configure test actually links together the results for two
> >    features (global_symbol_pipe and global_symbol_to_cdecl).
> 
> The following suggestion is an outrageous hack, so please feel free
> to ignore it:  What if the BFD library's LTO plugin handling code was
> enhanced to include a heuristic that would choose between code and data
> based upon the name of the symbol ?  So for "global_symbol_to_cdecl"
> it would choose 'data' and for anything else it would stick with its
> current default guess of 'code' ...  Obviously this is far from ideal,
> but with no other source of information available to it, the symbol
> name is all that the library has to go on.

I don't think such a hack will actually help libtool.

Since this is now a known portability issue we can and should improve the
configure test to detect this scenario reliably.

PS: I was able to work around the LTO function-versus-data link failure
by declaring "sym" like this:

  __asm(".equ sym_____, sym"); int sym() asm("sym_____");

Now my C code can successfully access the value of the "sym" symbol and
GCC doesn't seem to care if "sym" is declared as a variable in another
translation unit.

Libtool could possibly make use of this or a similar trick to work
around this bug as accurate symbol types would not be needed.
Presumably this won't work on every GCC target but it might be
good enough.

Amusingly, "nm" is also busted on objects using this trick with -flto,
showing a_____ as an undefined symbol which is not the case.  But that
shouldn't cause any issue for libtool's uses of nm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.