From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10838 invoked by alias); 15 Aug 2019 14:33:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 9850 invoked by uid 89); 15 Aug 2019 14:33:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=sk:assembl, H*f:sk:55b4acd, H*f:sk:0dBdA@m, pr91393_0.c X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Aug 2019 14:33:44 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 9833E28252B; Thu, 15 Aug 2019 16:33:41 +0200 (CEST) Date: Thu, 15 Aug 2019 14:57:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Martin =?iso-8859-2?Q?Li=B9ka?= , GCC Patches Subject: Re: [PATCH] Prevent LTO section collision for a symbol name starting with '*'. Message-ID: <20190815143341.m4t76ewfi4zn3ayl@kam.mff.cuni.cz> References: <55b4acda-9673-557b-5819-50bff07fa095@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2019-08/txt/msg01111.txt.bz2 > On Fri, Aug 9, 2019 at 3:57 PM Martin LiĀ¹ka wrote: > > > > Hi. > > > > The patch is about prevention of LTO section name clashing. > > Now we have a situation where body of 2 functions is streamed > > into the same ELF section. Then we'll end up with smashed data. > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > > Ready to be installed? > > I think the comment should mention why we skip a leading '*' > at all. IIRC this is some target mangling applied to DECL_ASSEMBLER_NAME? DECL_ASSEMBLER_NAME works in a way that if it starts with "*" it is copied verbatim to the linker ouptut. If it is w/o "*" then user_label_prefix is applied first, see symbol_table::assembler_names_equal_p So if we skip "*" one can definitly construct testcases of different function names ending up in same section especially when user_label_prefix is non-empty, like on Windows I think it is "_". > And section names cannot contain '*'? Or do we need to actually > indentify '*fn' and 'fn' as the same? For the testcase what is the clashing > symbol? Can't we have many so that using "0" always is broken as well? We may have duplicate symbols during the compile time->WPA streaming since we do not do lto-symtab at compile time and user can use asm names that way. This is not limited to extern inlines, so it would be nice to make this work reliably. I also plan support for keeping multiple function bodies defined for one symbol in cases it is necessary (glibc checking, when optimization flags are mismatches) for WPA->ltrans streaming. I was always considering option to simply use node->order ids to stream sections. Because of way node->order is merged we area always able to recover the ID. It is however kind of nice to see actual names in the objdump of the LTO .o files. I would not mind that much to see this go and it would also save bit of space since symbol names can be long. Honza > > Richard. > > > Thanks, > > Martin > > > > gcc/ChangeLog: > > > > 2019-08-09 Martin Liska > > > > PR lto/91393 > > PR lto/88220 > > * lto-streamer.c (lto_get_section_name): Replace '*' leading > > character with '0'. > > > > gcc/testsuite/ChangeLog: > > > > 2019-08-09 Martin Liska > > > > PR lto/91393 > > PR lto/88220 > > * gcc.dg/lto/pr91393_0.c: New test. > > --- > > gcc/lto-streamer.c | 15 ++++++++++++--- > > gcc/testsuite/gcc.dg/lto/pr91393_0.c | 11 +++++++++++ > > 2 files changed, 23 insertions(+), 3 deletions(-) > > create mode 100644 gcc/testsuite/gcc.dg/lto/pr91393_0.c > > > >