[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: marxin.liska at gmail dot com
Subject: [Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
Date: Thu, 09 Jan 2020 08:14:30 +0000


--- 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]