[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: nbowler at draconx dot ca
Subject: [Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
Date: Thu, 09 Jan 2020 14:15:17 +0000


--- Comment #5 from Nick Bowler <nbowler at draconx dot ca> ---
(In reply to Martin Liška from comment #4)
> 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?

Probably not.  The features being probed, by their very nature, generally
need to be used prior to linking.

The configure test is actually working essentially correctly.  Libtool
has determined that the feature being probed (the ability to produce
C declarations from nm output) will not work.  This appears to be a
reasonably accurate assessment of the situation when using GNU nm
with LTO.

On the libtool side we can probably make the following improvements:

 - The configure test actually links together the results for two
   features (global_symbol_pipe and global_symbol_to_cdecl).  So if
   one doesn't work libtool assumes neither works.  They could perhaps
   be tested independently as I think global_symbol_pipe is probably 
   mostly OK in spite of this bug.

 - The documentation should mention the possibility that these variables
   could be empty on some targets if the feature is not supported.

 - The export-symbols-regex feature should probably not fail gratuitously
   on targets where global_symbol_pipe is not supported.

 - Investigate alternate ways to implement global_symbol_to_cdecl on
   GNU targets which avoids the LTO linking error.

 - Investigate workarounds for this particular nm bug (e.g., libtool
   could enable -ffat-lto-objects and using nm --plugin '' which restores
   working nm behaviour).

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]