From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id E179D38560B8 for ; Fri, 12 May 2023 21:57:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E179D38560B8 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-643b7b8f8ceso5772496b3a.1 for ; Fri, 12 May 2023 14:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20221208.gappssmtp.com; s=20221208; t=1683928661; x=1686520661; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=JOJt5rzU/1k62mfYEYMyVKoT3UVxpOpPKnewFb+4Ij4=; b=xbi3JxrHA1UcU2dgMPlrizNFEo8VlkThUpmPAlmP8to47HdYPa8klBuHDpe0kGzDfB xG7kMPzF76EhCbaV0vdkJFQEmNHpltlrHROR+Ejay+w6Lf0oFlKpjQ1eL8Iao3mKiWav duj5akXAJf7pvaDUafWifVLSZo3jos/NptcJZbNpLdMPhLQi/KGAXyfWO83Os8LRsELw +yPigPpknXMghAB5GNYFmEtisNwgSMHXYcABXd7EDl8G5ehbAZyJ2klrUOW7Xp6EpJO5 CchvS4xBJpy6twrCo6vZaufwxSZMRkzXMOrr2MB8M+nF15xCtM/MjeYnjT6zDwuThccw KKjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683928661; x=1686520661; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JOJt5rzU/1k62mfYEYMyVKoT3UVxpOpPKnewFb+4Ij4=; b=iyse51Ixy+JHCx4gZ0jvhvrc3oso/J6FljSyLgNecCz/Sc5BE9IfP3tePA3IWJdOOQ x2//aDehyUKINZ/xIwhC+cQjMLMbWARVZu/nmQpzwbPlteKdcG6IfP3dF5/SEDRCB6p5 /swTjhnCoOIol8Nne0suDOGDObIdNLBkLxPXZNNi0NsUh359NMQVsz+Q9dxjq9WTcGmy IrtA2WInWYr8ijIvK2N5rEUFIXr/eo0NLcu6u5vRNnSbZoZ8VSXmN3KpwlWx+pBCO1at r6J2VK7IKemQz5yHn15jboSbYjmHy+SZJ75DP+tjU80FjGyJlUG0TxD7qkd94eeAOc7a 4Y9g== X-Gm-Message-State: AC+VfDzSZ7dufByCCojTNFVc7zqbis1Pet7D5Pg6vq1mKeyoYoAvHmLF PP/g2w0QKSwe98IHUuHaIJQMDA== X-Google-Smtp-Source: ACHHUZ5DnzExzty3hs8dMeSeNWLaFgXmBrBgXvw3Sc4oMbfH53LwWQYjE9R+uUBByxW1V8/IZP8PcA== X-Received: by 2002:a17:903:338e:b0:1a8:ce:afd1 with SMTP id kb14-20020a170903338e00b001a800ceafd1mr24200434plb.20.1683928660679; Fri, 12 May 2023 14:57:40 -0700 (PDT) Received: from localhost ([135.180.227.0]) by smtp.gmail.com with ESMTPSA id m17-20020a170902bb9100b001aaef9d0102sm8407330pls.197.2023.05.12.14.57.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 May 2023 14:57:40 -0700 (PDT) Date: Fri, 12 May 2023 14:57:40 -0700 (PDT) X-Google-Original-Date: Fri, 12 May 2023 14:57:38 PDT (-0700) Subject: Re: global pointer gets overwritten with dlopen(3) on RISC-V In-Reply-To: <20230512210908.osbbhn4hl5pjldof@google.com> 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 From: Palmer Dabbelt To: maskray@google.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 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. > 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.