From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 5D0713858290; Tue, 12 Jul 2022 02:32:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5D0713858290 Received: by mail-pf1-x42d.google.com with SMTP id b9so6300146pfp.10; Mon, 11 Jul 2022 19:32:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rstxU1QF+vQfHJS/fgKIniqGBL8LnojZluUXf6Lpl64=; b=mDX0YZo4tKxi9ANrPh/LzbdJWJP5F3Jij5uakKc9/IB2cVkaytk/NgrYccoMtx6w84 E2TK3tMG0NGPQ0GNtnF/TwVcg6zKx9csAHcIgQqoxzmhYWCf3uohxH90M7/cM4y2xfNb P7o7yTSDHvRO8IWROgmhecDU/e6UBlufAUn1LfWwytJ45vbvD2P3Zp6Fwkl1E5N/GqPW zj/pnjYf5D2ny214iS8oimbTucP4vT5OIUd7tnv4q4Q3XVoLxHH+8GAQMRh+kaFCTUDD tlHT50kfGN3/HFm66j95O9G4/oe8a+Dus6SmLUDDE5NcP5vKVFFGSEq9OQ2WQMxS2AqR ARuQ== X-Gm-Message-State: AJIora9DwvtAoh5pKRBIHXQ3nk++JETHx/skAK2BI8M00xIHbprL5XC2 ToxY4X+hGF/1PsGMiU6DKhc= X-Google-Smtp-Source: AGRyM1tHNyWRqMQrQ8aySdsoR3BZxnMJqbDEKBb44pAhjWQVtNdnIIQOliBsvSBgZaLWwFVPvl1fPw== X-Received: by 2002:a63:754:0:b0:415:4578:248a with SMTP id 81-20020a630754000000b004154578248amr18638567pgh.196.1657593129251; Mon, 11 Jul 2022 19:32:09 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id u15-20020a17090341cf00b0016a6cd546d6sm480884ple.251.2022.07.11.19.32.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jul 2022 19:32:08 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 74E5A1140149; Tue, 12 Jul 2022 12:02:05 +0930 (ACST) Date: Tue, 12 Jul 2022 12:02:05 +0930 From: Alan Modra To: Xi Ruoyao Cc: Adhemerval Zanella Netto , Carlos O'Donell , libc-alpha , binutils@sourceware.org, caiyinyu , Wang Xuerui , Fangrui Song , liuzhensong Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release) Message-ID: References: <7aba5486-ac02-2088-221e-513a6892817a@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3030.9 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 02:32:14 -0000 On Tue, Jul 12, 2022 at 08:48:18AM +0800, Xi Ruoyao via Binutils wrote: > > The R_LARCH_NONE issue should only affect performance, > > since it should be ignored by loader although I am not sure without > > understanding better the issue. R_*_NONE relocs are harmless in an executable or shared library, if their presence is due to overallocating space for relocations. Of course, if ld should actually be emitting some other dynamic reloc type then that is a more serious problem. > Fangrui suggested [2] we should assume R_LARCH_NONE does not exist to > simplify the code and catch ld bugs earlier. Yes that will annoy your user base into reporting bugs. How much do you want to annoy them? You might like to consider why other major architectures with mature linkers process and ignore R_*_NONE relocs in the loader.. -- Alan Modra Australia Development Lab, IBM