From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 0A042385736A for ; Tue, 12 Jul 2022 07:34:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A042385736A 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-x62d.google.com with SMTP id mf4so11605946ejc.3 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=aAz8jqp05/XDbVCK2761dHDhzUULivOEbrZliug/L+rV17eJ+y5DpStZ0VyS+7rAIP kbFSjDOo6sl02kexhGRSmO5bg/EpI+x9iYXZ5rLDN4aCVzE1oF2KgNSuE9H+l1iAu4aE 1+12V+EjdabFcX/3RrgypSIgaa/fc6wPgnK9fTrnjJ7E6Yjjrwxx6Z16pjA/jnXZzJ/h Y19B0OKS3TYYpld44k/zoURCkn5mfaRZuKKZvlPW7dLvzF2OkCSieJwBQ2lWbPnluAS4 zp4kwOTtl079Z2A39Xb27OFvzmYlpY4NqsSFoGp2T63+//7I9h+GGjuX2xmlPOACEect F5Fg== X-Gm-Message-State: AJIora9/WHF1LbdgnNBaeT3e6YfTBgWSao958uXA8vyHJMlPCZIrbQ26 TvvQOA62CWjAzH5IVZXPbSwILkHD+h8Bdnfe 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=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha 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.