From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 2036C3858CDB for ; Thu, 20 Jul 2023 14:32:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2036C3858CDB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 7E82D92009C; Thu, 20 Jul 2023 16:32:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 7C89592009B; Thu, 20 Jul 2023 15:32:49 +0100 (BST) Date: Thu, 20 Jul 2023 15:32:49 +0100 (BST) From: "Maciej W. Rozycki" To: Alan Modra cc: YunQiang Su , YunQiang Su , binutils@sourceware.org, Nick Clifton Subject: Re: [PATCH v2] MIPS: Don't move __gnu_lto_slim to .scommon In-Reply-To: Message-ID: References: <20230703103647.3162351-1-yunqiang.su@cipunited.com> <20230703105034.3163572-1-yunqiang.su@cipunited.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3488.8 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 20 Jul 2023, Alan Modra wrote: > > > I think the patch is OK, but the same should be applied to another > > > place to stop objcopy modifying __gnu_lto_slim. > > > > > > mips-linux-gnu testcase after running make check: > > > binutils/objcopy ld/tmpdir/pr15323a-r.o ld/tmpdir/xxx > > > then inspect ld/tmpdir/xxx with readelf. > > > > > > I'm going to apply the following to mainline, and will also apply to > > > the 2.41 branch tomorrow if no one objects. > > > > You are the author of this code, so I guess you know what's going on > > here. I still don't understand the circumstances that cause linker.c to > > reject this symbol if it's in an SHN_MIPS_SCOMMON rather than SHN_COMMON > > section, and the relevant git change descriptions (going back to commit > > b794fc1d1c3a ("Warn for ar/nm/ranlib/ld on lto objects without plugin")) > > do not explain it, so I'd appreciate if you got me enlightened. > > It isn't anything in linker.c, I believe the problem occurs in the lto > plugin which processes object files using libiberty/simple-object*. > Code in libiberty/simple-object-elf.c removes SHN_COMMON symbols, > which for most architectures removes __gnu_lto_slim, but not on mips > if the symbol is moved to SHN_MIPS_SCOMMON. Then the symbol appears > in lto output files, resulting in linker errors like: > /tmp/ccg5JkW9.debug.temp.o: plugin needed to handle lto object It seems to me then we should be fixing libiberty instead, to also remove SHN_MIPS_SCOMMON symbols, for whatever intent it's done, shouldn't we? > I haven't actually looked at this under gdb to see exactly what is > going on for mips, I'm relying on memory from doing so for powerpc a > while ago. Completely understood. Maciej