From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 226C53858C2F for ; Thu, 20 Jul 2023 22:44:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 226C53858C2F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3a43cbb4326so884769b6e.2 for ; Thu, 20 Jul 2023 15:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689893057; x=1690497857; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2h0NTE0q6TqwrOXMngh+dEoLR8v7yeb2BXB9jWRSYjg=; b=oqy39UPAGoiL1SBbG5guVHupeynOjDxTbBl4RXji7isLERWxLibDfhS3OKLG28x1jF tfXwpY9lTwh6q0nTGijAiwOLJ+VxbJvF8Lp2o0ePKEL7b9jlcAGFzn8l0quUtzcM2ZKl r70S4bxhsGFYkK1pdu7+KIYIxej6PlX2aoEDfbZh0Aray6yaZe/may7BKfHiyEDhLeMe WXLuLv6YD329T4/GgpZGSbTDzM4v2ynwpXCZsRBtyw85KhFAeL0Q9AspCW8DhnhEj7mq ffg/1rrKs4efUPMFykS/jrOD6MB42noPm1aAfVN5CbZMFWuvs/PhzyzCN3myAyNOcqat XbSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689893057; x=1690497857; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2h0NTE0q6TqwrOXMngh+dEoLR8v7yeb2BXB9jWRSYjg=; b=ZJWnZMXE6K4ejRZg16qj3FwpgJGnoVDEyr+uhapHGXYTkouvDEPt+1jGQ9lArfi3zE Jd1EqHIrzQGh3m2aMVdhSkxUBdjWauGMe0Y/k/ilT/6VmskjKm5A1xo5aDuwpMGkZ2K7 +9f1oWcNoh3zE0RxoirUrrVUZu5qvpL5yqazYp7TfzLSXFoMK33aJk8tQBxL8a1vBYnt LCFffFs7gvj6QPw+s1vM8WUI/bnePrxeW35r0JxrHX+yZ81VmmoJ96VROxfxqlPgciVJ FP6tfddmkKKC7FhObuzRvCu7cglAE/BnIK7NSb95ZowNRyI7M1DolE5T7mEImbAkPKNg LXNg== X-Gm-Message-State: ABy/qLY0p1GxUWQ74CTcrcyhEKLJsdgZvV4+qBpKDyCiys5vJ55VsH7B VDTQTE/kDfGTG+9YSPRf8l8= X-Google-Smtp-Source: APBJJlGGhbUzuKuv7rbYb3Zt9TNBDFyu71tdleCFp/BxrErZ9RaVwHzpNHQm/eXuP1SnrN/wreXfpw== X-Received: by 2002:a05:6808:1a23:b0:3a3:76c6:a46f with SMTP id bk35-20020a0568081a2300b003a376c6a46fmr309151oib.38.1689893057426; Thu, 20 Jul 2023 15:44:17 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:4d08:cebd:d73f:b794]) by smtp.gmail.com with ESMTPSA id g7-20020a17090ace8700b00263d7c5323dsm1410210pju.49.2023.07.20.15.44.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 15:44:16 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 2A7CB1140CAF; Fri, 21 Jul 2023 08:14:14 +0930 (ACST) Date: Fri, 21 Jul 2023 08:14:14 +0930 From: Alan Modra To: "Maciej W. Rozycki" Cc: YunQiang Su , YunQiang Su , binutils@sourceware.org, Nick Clifton Subject: Re: [PATCH v2] MIPS: Don't move __gnu_lto_slim to .scommon Message-ID: References: <20230703103647.3162351-1-yunqiang.su@cipunited.com> <20230703105034.3163572-1-yunqiang.su@cipunited.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3027.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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, Jul 20, 2023 at 03:32:49PM +0100, Maciej W. Rozycki wrote: > 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? It would be quite reasonable to change the libiberty code to test for EM_MIPS and SHN_MIPS_SCOMMON, or to discard __gnu_lto_slim by name. (The only reason that simple_object_elf_copy_lto_debug_sections removes SHN_COMMON symbols is to remove __gnu_lto_slim.) However the symbol is a marker only, so I think it is also entirely reasonable to stop mips ld -r or objcopy from modifying it unexpectedly. -- Alan Modra Australia Development Lab, IBM