From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 7ED2C3856275 for ; Fri, 12 May 2023 21:09:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7ED2C3856275 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-x62d.google.com with SMTP id d9443c01a7336-1a950b982d4so548485ad.0 for ; Fri, 12 May 2023 14:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683925751; x=1686517751; 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=k62LPJu1mu5ksdHtM76WNhy74EMktdxrHWeAw5eXqyg=; b=iDOA1n7NrId6gucps+GDeSbQsWWC5oShfkku4b8AP+M1lgPK8RJRwnN0p4Ku7eST7N vmY9Irl6ip+dp5VAoh+04H0MJBBl00y9IbdbSAXtXySW8YHWmpl/6Wl/rnCylPkI5roO s0YoOm4ksAbEpe/A8Z48ONQyVGq6fOXXRnPvNne9PhiAJwubgcTtAYkuotvcAlt7ePkx 0yJt/CgzxFJBdlJw2YkJmVF5SaJOVDwf6mScIjaxu3o2ZtK62R3zZRaX54H3HDEsroIA oFo4+aDEkm7TRDVm5dAV8RkruNTJIjizdiJKL5y717kpHQwqRKBm0Vvz8QZXr9Z9meJ6 WRlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683925751; x=1686517751; 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=k62LPJu1mu5ksdHtM76WNhy74EMktdxrHWeAw5eXqyg=; b=YOh4gGHJLHtL0lFgLNBqtSUZwsT/evqDTsMoBJ4nU659M9/vYZ44BfYzlfLSzzQULw b0DJYwk5XVEPVhKpR+nfIsz5THumVSZPQ05Nbc9kNR1U+UIyOXIFYztTuGnNzXNWsuDj erP+1/wl1K+Yj4wUKdz4wVGGDCpf+BfsajBwNizHi5/rSwtDpFduTYne6ntIaifH6wFM gP7d8ew4JxgaqXWYln/awFrLaqF7XX3zqQhqdG5sfwwh5iDSpJ+2DYAxL1QqzYhJdMJJ iJqimIIfs4gsnxDn1hafhDhkybEK1vzMKk4CALbc0CrLdclbzsEW8i/70kDkSAmsrnVa DSLA== X-Gm-Message-State: AC+VfDwhxreUfCZb808jFC2EG69LNPvD8p06ybN62sqIHREJvOIU1nBM dQTw3RCAwntv8x+jWPk7vT/nww== X-Google-Smtp-Source: ACHHUZ7Ru/LlUwjDqOB/6BY9bzv5Urfk6S0D231NERrMu1AprxM+TpCmcH99j3LLWr4AKYAS+l5rOA== X-Received: by 2002:a17:902:a415:b0:192:8a1e:9bc7 with SMTP id p21-20020a170902a41500b001928a1e9bc7mr397041plq.0.1683925751191; Fri, 12 May 2023 14:09:11 -0700 (PDT) Received: from google.com (25.11.145.34.bc.googleusercontent.com. [34.145.11.25]) by smtp.gmail.com with ESMTPSA id b9-20020a170902650900b001a6dc4f4a8csm8462620plk.73.2023.05.12.14.09.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 May 2023 14:09:10 -0700 (PDT) Date: Fri, 12 May 2023 21:09:08 +0000 From: Fangrui Song To: fweimer@redhat.com, Palmer Dabbelt Cc: 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, Jeff Law Subject: Re: global pointer gets overwritten with dlopen(3) on RISC-V Message-ID: <20230512210908.osbbhn4hl5pjldof@google.com> References: <877ctdpaww.fsf@oldenburg3.str.redhat.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 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. 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.