From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id C809A3857405 for ; Tue, 12 Jul 2022 07:34:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C809A3857405 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-ej1-x633.google.com with SMTP id b11so12753693eju.10 for ; Tue, 12 Jul 2022 00:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4PrVsDR3AZPJTwAwmeSU4F5Jnt0A6LeaPedIKaWyGcM=; b=T1EIt25ItKN33M0gPLdrAYIOSl1IMc1Sh36cdsAxHq7LR/W2ZH1WF3ADsuyJSFlv5i xTOUsF80BJhvG/3XubrbwQWMEsWmCpWXi8zRiV87wnjAQOaIAHB1jAkZHVg/gtY/m90Z gkKr65TxU2rIcLAFkHTOsonXz+uj26jJh+yRTw/BfehJ/2XK6LAy10nIyx4TWbehx/gt vFDnU1IBwGG6jhJFc54fgf35+VZs3X4VYoFoHIFxOJwOOUM/iDkT3gvB2+oerLtZ/o72 7biE93Ho9ArXKvkk/jrUwvoGvk4CKNdX/of8gf3Hz/YjooshLNBFslqfpLCHCtip041Z MhDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4PrVsDR3AZPJTwAwmeSU4F5Jnt0A6LeaPedIKaWyGcM=; b=IO41ZAzjs4eiXRtCjIg2dkTLYx3ZDGQAY/lqZ32R59gaSgDLuqq055V0BCu7W0om7C c60EP6JHp926pV+KoIZ/A9dUvF9EMXg9Up86RXSpKUiK6orovPHgnW7XPhmetsO6eHBn 8SwB68TRnYQ/zNipPtCWYfqCnJGxUDbqM5X50KV7rPybkXi5hv/N8NDDAH9OeS/EiFBa qF/CSndG19YiYaeNniSE+6pxIxrrUABEU93jd9gHIYTGU/sB/FNWQc5DmD9HWPlBd3PR M8xFzd4+RyPOCY//bybZxz6ko0hNPH97TI1IyUzcf68zrKCHSw6ePD9MUJgmNqKiZwf/ t8gA== X-Gm-Message-State: AJIora9ouRKMQ55npgY7ufI6FcBg0bydUBv0W5sK/NQWs93v9MRkIx35 sRU3geZJZNXBjuHkV2lyY+uUWn/L9rTdCXfK X-Google-Smtp-Source: AGRyM1tSRUimVM9vQqvtm4HjFaQMKuGGoWUDUCJuLd+X9gRejqBARGMhqUrsYf9sj8sqi4fq2diuhQ== X-Received: by 2002:a17:907:7394:b0:72b:44ff:5cec with SMTP id er20-20020a170907739400b0072b44ff5cecmr14006531ejc.670.1657611252480; Tue, 12 Jul 2022 00:34:12 -0700 (PDT) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com. [209.85.128.48]) by smtp.gmail.com with ESMTPSA id ca15-20020a170906a3cf00b0072b2cc08c48sm3465535ejb.63.2022.07.12.00.34.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 00:34:11 -0700 (PDT) Received: by mail-wm1-f48.google.com with SMTP id n185so4211400wmn.4; Tue, 12 Jul 2022 00:34:11 -0700 (PDT) X-Received: by 2002:a1c:750e:0:b0:3a2:b42f:ec2c with SMTP id o14-20020a1c750e000000b003a2b42fec2cmr2289211wmc.153.1657611250770; Tue, 12 Jul 2022 00:34:10 -0700 (PDT) MIME-Version: 1.0 References: <7aba5486-ac02-2088-221e-513a6892817a@linaro.org> In-Reply-To: From: Andrew Waterman Date: Tue, 12 Jul 2022 00:33:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release) To: Fangrui Song Cc: Alan Modra , libc-alpha , caiyinyu , liuzhensong , Xi Ruoyao , Wang Xuerui , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 07:34:16 -0000 On Mon, Jul 11, 2022 at 9:25 PM Fangrui Song via Binutils wrote: > > On Mon, Jul 11, 2022 at 7:32 PM Alan Modra wrote: > > > > 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.. This thread attracted my attention because of the stray mention of RISC-V. I'd just like to comment that this appears to me to be an aesthetically motivated change. It's hard to support breaking existing code on this basis, even if the code was theoretically ABI-incompliant to begin with. Why can't we just leave well enough alone? > > If a linker port has a high confidence level, removing dynamic > R_*_NONE support from the loader shall be the right thing. > I can understand that there may not be the case in GNU ld as I've seen > such bugs in riscv (e.g. > https://sourceware.org/bugzilla/show_bug.cgi?id=24673), too (I think > gold, lld, and mold make it difficult to make such bugs). > But I did wish that a fresh port of a new arch in binutils had fixed > all such bugs. I realized it might be the case for LoongArch, so > keeping R_LARCH_NONE support in glibc ld.so may be fine.