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

[marxin.liska at gmail dot com]

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

--- Comment #4 from Martin Liška <marxin.liska at gmail dot com> ---
(In reply to Nick Bowler from comment #2)
> Summary of the issue in libtool:
> 
> libtool needs to produce C declarations for arbitrary symbols based on nm
> output, in order to implement various features such as dlpreopen which
> depend on putting symbol values into C data structures.
> 
> Some linkers (apparently this the case on HP-UX) are strict and won't let
> function declarations refer to variables and vice versa.  So the nm symbol
> type is used to produce either a function or variable declaration, as
> appropriate.
> 
> Unfortunately, with LTO enabled the GNU linker (or does GCC do everything in
> this case?) seems to also have this restriction: it is an error for a
> function declaration to refer to a variable or vice versa.

Yes, it's critical for the compiler to not mix different symbol types (fn, var)
with the same name

> So libtool uses
> the symbol type reported by nm to produce function declarations for
> functions, and variable declarations for variables.
> 
> Unfortunately, with LTO enabled then GNU nm does not distinguish between
> functions and variables (however, clang and llvm-nm seems to be fine in this
> regard).

That's true, but it's only related to .o files (LTO bytecode). If you link
a final executable (or a shared library), you'll get proper type information:

$ cat conftest.c
int foo;
int main() { return foo; }
$ gcc conftest.c -flto -fno-common
$ nm a.out | grep ' main'
00000000004010f2 T main
$ nm a.out | grep foo
000000000040402c b foo

Would it be possible to libtool to make the detection on a binary executable
or a shared library?

> 
> There is no obvious way to work around the LTO function/data declaration
> issue in C code.  It seems libtool has to know, in advance, whether any
> given symbol is code or data in order to produce a declaration that will
> link successfully.
> 
> I see several options that would work to resolve the libtool problem:
> 
>   - Fix GNU nm to report functions and variables differently (best).
>   - Fix GNU ld (or GCC?) so that it is not a hard error to refer to
> variables with function declarations or vice versa, so the nm issue does not
> matter.
>   - Figure out another way to get the value of a symbol in C code without
> knowing anything other than its name.

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