[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Arvind Sankar changed: What|Removed |Added CC||niveditas98 at gmail dot com --- Comment #11 from Arvind Sankar --- While checking what happens during gcc-10 bootstrap with libtool configuration, I noticed that the current test code doesn't work with C++. lt__PROGRAM__LTX_preloaded_symbols gets declared as a const struct [], which has static linkage in C++, and at any non-zero optimization level that test file gets completely eliminated. So the pipe is assumed to always work if configure is running with a C++ compiler. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru, ||toolchain at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #10 from Nick Bowler --- (In reply to Martin Liška from comment #9) > > 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. > > Hello Nick. > Have you made a progress about the upstreaming of the workaround? I did actually implement this trick but unfortunately it turns out that symbol references in asm cause breakage w/ GCC's LTO when linking against static libraries. So this is not a workaround that can be used in libtool, sadly. I hope to investigate other options to work around this issue in libtool. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #9 from Martin Liška --- > > 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. Hello Nick. Have you made a progress about the upstreaming of the workaround? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #8 from Alan Modra ---
To reinforce Nick's comment #1 about the plugin api, this is what we get in
bfd/plugin.c:bfd_plugin_canonicalize_symtab for gcc -fno-common compiling
char nm_test_var;
int nm_test_func (void) { return 0; }
(gdb) p syms[0]
$1 = {name = 0xb33800 "nm_test_func", version = 0x0, def = 0, visibility = 0,
size = 0, comdat_key = 0x0, resolution = 0}
(gdb) p syms[1]
$2 = {name = 0xb33820 "nm_test_var", version = 0x0, def = 0, visibility = 0,
size = 0, comdat_key = 0x0, resolution = 0}
There isn't anything to distinguish variables from functions, and so nothing
can be done in nm.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #7 from Nick Bowler ---
(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.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #6 from Nick Clifton --- (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. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #5 from Nick Bowler ---
(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'
> 004010f2 T main
> $ nm a.out | grep foo
> 0040402c 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.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added CC||bfriesen at simple dot dallas.tx.u ||s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #4 from Martin Liška ---
(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'
004010f2 T main
$ nm a.out | grep foo
0040402c 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.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Calvin Walton changed: What|Removed |Added CC||calvin.walton at kepstin dot ca --- Comment #3 from Calvin Walton --- *** Bug 25356 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Nick Bowler changed: What|Removed |Added CC||nbowler at draconx dot ca --- Comment #2 from Nick Bowler --- 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. 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). 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.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1 from Nick Clifton ---
Hi Martin,
I think that this problem is due to a weakness in the plugin-api. The
specification of the ld_plugin_symbol_kind enum only has five values:
enum ld_plugin_symbol_kind
{
LDPK_DEF,
LDPK_WEAKDEF,
LDPK_UNDEF,
LDPK_WEAKUNDEF,
LDPK_COMMON
};
So it does not have a way to distinguish between code symbols and data symbols.
Hence when a defined symbol is seen the BFD library has to make a choice, and
it chooses to assume that it is a code symbol. Given that section names have
also been discarded by this point, it is impossible for the library to
distinguish between code and data symbols.
So unless we create a new version of the plugin API, I think that this will
have to remain as an unsolved problem. At least that is my take on the
subject. Lets see if anyone else has any better ideas.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
