From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 426743854158 for ; Fri, 12 May 2023 20:35:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 426743854158 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-64a9335a8e7so8343287b3a.0 for ; Fri, 12 May 2023 13:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683923751; x=1686515751; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=y7u/VrSP5dL5UX1fNJ8+uVZgRA74fVcBvTdhMZiZsZ4=; b=J5lr79Hw1bdi9X0I4XtgWy+HK0oqqdC7UVRTrI1btbhJjAAen3F+3Uk+j6q1JyE7ON 3Yg3B42KtPYa5XX89NwaD3pT/7qrBdOzAmaUyjh4pvyi5Z1u5jANxD1eF9Mh50f7LWeG 252Y0fKKO5xjT3jqDCQmk5MYzM0kx6J6WlzpyWK26o9x2iBzeqIMZt/ribeUvRqMt1p5 JLneVZCMHWQBCbXcG87sT9p9xrvetlkOo39oz856dvaYzzq+4knBGCXqMLW/FmqXbDLO rdaP4/ggNSG1wZ+DcLK5w9xYt1dSpm0FYggR8gKXG3InB0RMFjH2e71WD2g/LRD0zmlz Uitg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683923751; x=1686515751; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=y7u/VrSP5dL5UX1fNJ8+uVZgRA74fVcBvTdhMZiZsZ4=; b=YCnTwC+l8DmwTPeK3RWdBg9feWu+M1gIoZkulJFwBS8rdqnF9DeHioOYldXxin71EV 7KedSIFQYG0hDgepu5ApsLVvNSOZaRcAHFx7V2WvNhnt5kr35UUW0pCU91jzVdIFw6Yh 9z70TEm591XsMDzgNKapDBy6AkFpyINzWCNf/B+k3jhYLHmRjwEA1IhdTrlrKa7Bw9v7 4I+u7DqhHSGgdA5hr5kF0s0VGtyhkcAY28ozvr2E3Wy+GhumKFP/hl9gn0zRNpGHyx3/ XcxjTmKZLjBWyvYSqx/nBRmGxWybpvaAdipN8riKWYvWBFayayKJR/3C0EXTptQW5yAW On1A== X-Gm-Message-State: AC+VfDwS4g+6RTOCTo0ERhHyka9dWykEzcc1t3dcdtfq+aan4PwjOtod E2cpv8JAk/oOJBZOo2FNN64sFmFfj9k= X-Google-Smtp-Source: ACHHUZ5qzOsIYKDr8y0t9+WbzSA2qhi/TyU54VYY344AWePJjsKijO0HbG+SRlJ69mQXDigfheN0HQ== X-Received: by 2002:a17:903:192:b0:1ab:1260:19de with SMTP id z18-20020a170903019200b001ab126019demr33371482plg.11.1683923750447; Fri, 12 May 2023 13:35:50 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id n10-20020a170902d2ca00b001aaf13db1acsm8334095plc.276.2023.05.12.13.35.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 13:35:49 -0700 (PDT) Message-ID: Date: Fri, 12 May 2023 14:35:48 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: global pointer gets overwritten with dlopen(3) on RISC-V Content-Language: en-US To: libc-alpha@sourceware.org References: <877ctdpaww.fsf@oldenburg3.str.redhat.com> From: Jeff Law In-Reply-To: <877ctdpaww.fsf@oldenburg3.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_INFOUSMEBIZ,NICE_REPLY_A,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 List-Id: On 5/12/23 14:11, Florian Weimer via Libc-alpha 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. However, that value is probably a little low. There is a really interesting little bug in the interaction between how we place gp and how we determine if an address computation is relaxable. The net result is for relatively small data segments we can fail to relax address computations that we should be able to trivially cover with gp based addressing. This showed up as a clearly measurable runtime performance regression in spec2017. leela or deepsjeng, I can't remember which offhand. It would also likely be a size issue, though I rarely look at those size issues. Knowing that I still question if it is worth the effort to relax. Others have much more strongly held positions. Jeff > > Do we have a reproducer? Is the issue actually about gp relaxation for > the main executable? > > Thanks, > Florian >