From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by server2.sourceware.org (Postfix) with ESMTPS id B77D5393FC2E for ; Mon, 9 Mar 2020 09:30:10 +0000 (GMT) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7FB53ACBD; Mon, 9 Mar 2020 09:30:09 +0000 (UTC) From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Subject: [PATCH][RFC] API extension for binutils (type of symbols). To: gcc-patches@gcc.gnu.org Cc: "H.J. Lu" , Richard Biener , Jan Hubicka Message-ID: <1ab500be-a957-7dde-8bad-c94fbf8483ab@suse.cz> Date: Mon, 9 Mar 2020 10:30:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Language: en-US X-Spam-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 09:30:12 -0000 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 * lto-streamer-out.c (write_symbol): Stream symbol type. include/ChangeLog: 2020-03-09 Martin Liska * 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 * 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(-)