From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 97B233857727 for ; Fri, 12 May 2023 22:34:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 97B233857727 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1a950b982d4so559955ad.0 for ; Fri, 12 May 2023 15:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683930864; x=1686522864; 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=hZ+HmMoXuxjzy1DsE98RP3Pct1pggIyXv0r4ySWhRDM=; b=3OAbS1yQIZO/W420j7pNjFoeBzHEQ0lrYYWrad2cxFfPbD4eBvqcm8B2liNz91sZu9 VNCVa4DTUokJki7DtGJ5+9g/rX4Tu06/8PRV4fCkw4P5E69n3TEYI3pKFWdQIqZS7nGk 95nXnrFnCohZPHam4g5lQLSXbZt8Vvg86KD7R0QwCqvLgBVFMAv8Qedm5sxss7EzeO/K mPlmbtEvaO2RPdJroIB3jL4hT8zrabW34Fm/RRNuAgqhfePXAX2wR6oGNuobqc+SPqGW /9/aupyiuLhGgyTY/JvI8SRuB/NZyJlV9lnQjnPtUXWypM3hqng6TrcGlRMMtjZw2ymc rGgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683930864; x=1686522864; 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=hZ+HmMoXuxjzy1DsE98RP3Pct1pggIyXv0r4ySWhRDM=; b=Z0jTyeViB8LuTGmFc66WCf45Scwcq3NkI330j7557reDOJfLLgaJrudKmgTX4sBWxV BGQFjXZpeXxY5NGXJPKdCbDSuDng19yqKDv4Aq3M5M38yiZfGZIBAI8Fei7R0adeJ46R hAawyM9RJTccixGnSQeYlMp2UV5Hzy/r057L4upaoloZLb6L5DE+F2IApTHH+uqCDbjy ZvyU5rrhUGuCPtdX9O3Ik1Ka7bl/jgsMpeex4YBkrH7dfnZzLW/sldlDN+F/SDGFYNEY jKhIYRETZk8ZDfg7V9MZeixgOfvWEtZ2tPQT/eD6U4TJLrc5Xbq0A4wTfHAByzytaRtA hN7w== X-Gm-Message-State: AC+VfDyyvBq0JJb7xIP4RUIDMXhKuddAf1g7i/Ibp9lsQahZuU3ZEQQF 3sCpMo8XoU1aJBEB+SskpN1iew== X-Google-Smtp-Source: ACHHUZ5rN3k1aWjgjQ3daSxhLkVrs+fJ3mrHqhrSxXp6u31YiyfmZQWb4S0MJ7CQ7o15Q6uXHZE2oA== X-Received: by 2002:a17:903:489:b0:1a6:760c:af3d with SMTP id jj9-20020a170903048900b001a6760caf3dmr391486plb.16.1683930864303; Fri, 12 May 2023 15:34:24 -0700 (PDT) Received: from google.com (25.11.145.34.bc.googleusercontent.com. [34.145.11.25]) by smtp.gmail.com with ESMTPSA id n13-20020a170903110d00b001ac741db80csm8489733plh.88.2023.05.12.15.34.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 May 2023 15:34:23 -0700 (PDT) Date: Fri, 12 May 2023 22:34:21 +0000 From: Fangrui Song To: Palmer Dabbelt Cc: fweimer@redhat.com, l.stelmach@samsung.com, libc-alpha@sourceware.org, schwab@suse.de, adhemerval.zanella@linaro.org, joseph@codesourcery.com, binutils@sourceware.org, m.pikula@partner.samsung.com, m.szyprowski@samsung.com, k.lewandowsk@samsung.com, jeffreyalaw@gmail.com Subject: Re: global pointer gets overwritten with dlopen(3) on RISC-V Message-ID: <20230512223421.zvvbi374qx6kazel@google.com> References: <20230512210908.osbbhn4hl5pjldof@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-19.7 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 2023-05-12, Palmer Dabbelt wrote: >On Fri, 12 May 2023 14:09:08 PDT (-0700), maskray@google.com wrote: >>On 2023-05-12, Palmer Dabbelt wrote: >>>On Fri, 12 May 2023 13:11:43 PDT (-0700), fweimer@redhat.com wrote: >>>>* Fangrui Song: >>>> >>>>>>1. Make -mno-relax the default for ld(1) (on Linux?). We have no >>>>>>benchmarks whatsoever, but global variables aren't very popular in >>>>>>application code these days and the gp register allows access to a >>>>>>single memory page (4kB) only. No big deal really. >>>>> >>>>>I do agree that --no-relax-gp is a sensible default choice for GNU ld. >>>>>https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#global-pointer-relaxation >>>>> >>>>>Perhaps you can start a separate topic on binutils? :) >>>>> >>>>>According to a doc from SiFive about -static -mcpu=sifive-u74 builds, >>>>>https://docs.google.com/spreadsheets/d/14V7cPbyc80AcGHzsMaw9hYb232dzRbGCmTApnxj-SpU/edit#gid=0 >>>>>global pointer relaxation saves at best 0.5% size (I guess that refers >>>>>to .text. If we count all allocable sections, the percentage is likely >>>>>even smaller.) >>>> >>>>For a mature toolchain, 0.5% in code size reduction would be *a lot*, >>>>so I wouldn't dismiss that. >>> >>>That's broadly speaking why it sticks around. We've got a bunch of >>>headaches related to relaxation, GP or otherwise, but they improve >>>performance and nobody's figured out how to replace that yet. >>> >>>>Do we have a reproducer? Is the issue actually about gp relaxation for >>>>the main executable? >>> >>>In general we don't reference GP from shared libraries as we don't >>>have a GP save/restore scheme. There may be a bug floating around >>>here somewhere, in which case we should fix it, but the original post >>>sounds like it wasn't a supported use case. >>> >>>>Thanks, >>>>Florian >> >>Global pointer relaxation only applies to +-2KiB data relative to __global_pointer$ (= .sdata + 0x800). >>The area that potentially benefits global pointer relaxation is very small. >> >>0.5% code size reduction (relative to .text?) is the best case. I >>suspect the program somehow has a lot global variable accesses and >>placing these variables in .sdata helps. >> >>I've got results from Yingwei Zheng at PLCT lab using many >>configurations. The saving is like 0.1%. >>https://docs.google.com/spreadsheets/d/1Gz0h-C4U0toa9qELFtRaEWT_CzauE5JD9xMsLR8RyK8/edit#gid=1721258109 >> >>On the binutils side, we occasionally see patches to fix global pointer >>relaxation bugs, e.g. the patch just sent a few hours ago: >>https://sourceware.org/pipermail/binutils/2023-May/127413.html >> >>I do not know the embedded toolchain well, but for Linux desktop/server, >>disabling global pointer relaxation seems like a sensible choice. If we >>discover a better way to utilize GP (x3) in the future, disabling global >>pointer relaxation today will result in fewer compatibility issues. > >This comes up all the time, you're just pushing for a backdoor ABI >break. I get the desire to remove GP, if we were to be able to redo >things I'd also not have it, but it's in the ABI and we can't change >the binaries that exist. > >If you want a GP-free ABI then you should just go write one up. Then >it'll become a distro problem, and if it turns out that users also >don't want in then the GP ABI will rot and we can eventually deprecate >it. I am advocating for a change in GNU ld to make --no-relax-gp the default option, but I am not sure it can be considered an ABI break. When using ld --no-relax-gp, the conversion of code sequences to gp is disabled, thus eliminating an assumption related to global pointer relaxation. If an executable is relinked without global pointer relaxation, it should still function properly. To the best of my knowledge, there is no official documentation that designates linker relaxation as a mandatory feature. Relaxation schemes, including global pointer relaxation, are optional. Making an optional feature opt-in does not constitute an ABI break. glibc continues to initialize gp to __global_pointer$ to accommodate users who opt-in for global pointer relaxation. Removing the initialization of gp would indeed be an ABI break, and I have never proposed such a change. >>Haiku >>(https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/298#issuecomment-1344724796), Android, and Fuchsia >>have mentioned that they don't use global pointer relaxation.