Hi. With change of -fno-common default for GCC 10 we're facing serious problem with LTO where one can't distinguish in between global symbols and variables based on the output of nm: https://sourceware.org/bugzilla/show_bug.cgi?id=25355
$ cat nm.c char nm_test_var; $ gcc-9 nm.c -c -fno-common $ nm nm.o 0000000000000000 B nm_test_var $ gcc-9 nm.c -c -fno-common -flto $ nm nm.o 00000000 T nm_test_var H.J. decided to implement quite heavy solution which is about usage of lto-wrapper that takes a LTO object file and makes a final assembly file. The file is then utilized with nm. That has some disadvantages: - it's slow - using nm x.a can take very long time - way of finding lto-wrapper is quite hard-coded to location of LTO plugin - we face issues with multiple final object files: https://sourceware.org/bugzilla/show_bug.cgi?id=25640 That said, I'm suggesting to expect LTO plugin API to tell binutils whether a symbol is variable or function. That should help us to mark global variables with "D" in nm output. I would like to note that even with -fcommon, the nm output for LTO bytecode is far from perfect: $ cat bss.c int global_zero; int global_one = 1; $ gcc-9 bss.c -c -flto $ nm bss.o 00000000 T global_one 00000000 C global_zero I believe in this case we can mark both symbols with D as a reasonable guess. Thoughts? Martin gcc/ChangeLog: 2020-03-09 Martin Liska <mli...@suse.cz> * lto-streamer-out.c (write_symbol): Stream symbol type. include/ChangeLog: 2020-03-09 Martin Liska <mli...@suse.cz> * lto-symtab.h (enum gcc_plugin_symbol_type): New. * plugin-api.h (struct ld_plugin_symbol): New member symbols_type. (enum ld_plugin_symbol_type): New. (enum ld_plugin_tag): Add new tag LDPT_GET_SYMBOLS_V4. lto-plugin/ChangeLog: 2020-03-09 Martin Liska <mli...@suse.cz> * lto-plugin.c (parse_table_entry): Parse symbol type. --- gcc/lto-streamer-out.c | 2 ++ include/lto-symtab.h | 7 +++++++ include/plugin-api.h | 13 ++++++++++++- lto-plugin/lto-plugin.c | 12 ++++++++++++ 4 files changed, 33 insertions(+), 1 deletion(-)
