From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by sourceware.org (Postfix) with ESMTPS id 21D5A380FBA1 for ; Sun, 18 Dec 2022 23:09:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21D5A380FBA1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-f47.google.com with SMTP id gt4so7406938pjb.1 for ; Sun, 18 Dec 2022 15:09:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=niCI9vmQrBEzl81KAJMxnlGyY1Bko4CVXy2uLjntGao=; b=JSLZpvbti8fk0FQ0CDYG7NIdFhYyQVdDyqt252dgl+2j4joAp5XHRaqebJCrOvahI2 fy7jitmRcLliFGheKQdSy+Ph6N1gJfHwPbbYgh1BToCqMWtaMDgmUT/nbSf6SK6C1rdZ bOub+aJRq6nnZZhGsKDcfcfXKPzvhSqS99Mn3qoi/ch29DR1xC459bljpGk0l2Xs8QaZ yCfC58+ZjlmrdnmdmCvApyk9gmZowQjVan9HQdDEp8wgztOp32mtJrVEndM4Sar5prXY jExufgs9doIZQWEIIyT2iD5NCWdkiiLiKQzBDgW4627abN7Ukl2yl3ul9ojohGf7PjLj W+Tw== X-Gm-Message-State: ANoB5pmGaymIRreeqIl/rUEmTmQldbVvYrt4LeesNv8CSPEIqFn2JeXu 8a4N+NFzHnNbWC6sb8o0e7A= X-Google-Smtp-Source: AA0mqf5kMtDSLIoP1msOSQlh96tHUqjXjBnC9OJNtKIUCljXZ1LWMIoybtL53c6DZ+B/sAlZe9w93Q== X-Received: by 2002:a17:902:a711:b0:189:747e:97cc with SMTP id w17-20020a170902a71100b00189747e97ccmr38240956plq.26.1671404955085; Sun, 18 Dec 2022 15:09:15 -0800 (PST) Received: from localhost ([2601:647:6300:b760:4ee8:9f2e:9325:d757]) by smtp.gmail.com with ESMTPSA id x12-20020a170902ec8c00b00188f6cbd950sm5577907plg.226.2022.12.18.15.09.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Dec 2022 15:09:14 -0800 (PST) Date: Sun, 18 Dec 2022 15:09:13 -0800 From: Fangrui Song To: "Lad, Prabhakar" Cc: Lad Prabhakar , Palmer Dabbelt , Andrew Waterman , Jim Wilson , Nelson Chu , binutils@sourceware.org Subject: Re: [RFC PATCH] ld/emulparams: elf32lriscv-defs: Add support tune the text segment start address Message-ID: <20221218230913.b4zac6jsxg6sxywv@gmail.com> References: <20221216214310.13155-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20221218062404.cn75smc4pperrsd7@gmail.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=-9.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP 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 2022-12-18, Lad, Prabhakar wrote: >Hi Fangrui, > >Thank you for the feedback. > >On Sun, Dec 18, 2022 at 6:24 AM Fangrui Song wrote: >> >> On 2022-12-16, Lad Prabhakar via Binutils wrote: >> >On the RISC-V architecture the TEXT_START_ADDR defaults to 0x10000. On >> >some RISC-V platforms we want to set this offset to something else. So >> >this patch provides a way to tune the text segment start address. >> >elf32lriscv-defs.sh now checks for DEFAULT_TEXT_START_ADDR variable and >> >if being set it overrides TEXT_START_ADDR to the value set by >> >DEFAULT_TEXT_START_ADDR or else defaults to 0x10000. >> > >> >Renesas RZ/Five RISC-V SoC has Instruction local memory and Data local >> >memory (ILM & DLM) which maps between region 0x30000 - 0x4FFFF. When the >> >virtual address falls in this range the MMU doesn't trigger a page >> >fault and assumes the virtual address as physical address and causes >> >undesired behaviours of statically applications/libraries. Hence introduce >> >an option to tune the TEXT_START_ADDR. >> > >> >Signed-off-by: Lad Prabhakar >> >--- >> >Hi All, >> > >> >This patch is inspired from the current ld/emulparams/nds32elf_linux.sh file >> >where similar approach is being used and DEFAULT_TEXT_START_ADDR variable is >> >checked to adjust the TEXT_START_ADDR for the platform. >> > >> >I am not sure if this is the right approach the above issue has been discussed >> >on the ML [0]. >> > >> >[0] https://sourceware.org/pipermail/binutils/2022-November/124813.html >> > >> >Cheers, >> >Prabhakar >> >--- >> > ld/emulparams/elf32lriscv-defs.sh | 6 +++++- >> > 1 file changed, 5 insertions(+), 1 deletion(-) >> > >> >diff --git a/ld/emulparams/elf32lriscv-defs.sh b/ld/emulparams/elf32lriscv-defs.sh >> >index b823cedacab..026aef4714b 100644 >> >--- a/ld/emulparams/elf32lriscv-defs.sh >> >+++ b/ld/emulparams/elf32lriscv-defs.sh >> >@@ -27,7 +27,11 @@ case "$target" in >> > esac >> > >> > IREL_IN_PLT= >> >-TEXT_START_ADDR=0x10000 >> >+if [ -z ${DEFAULT_TEXT_START_ADDR+x} ]; then >> >+ TEXT_START_ADDR=0x10000 >> >+else >> >+ TEXT_START_ADDR=$DEFAULT_TEXT_START_ADDR >> >+fi >> > MAXPAGESIZE="CONSTANT (MAXPAGESIZE)" >> > COMMONPAGESIZE="CONSTANT (COMMONPAGESIZE)" >> > >> >-- >> >2.17.1 >> > >> >> Changing ld does not look like a good change to me. This tuning can be >> placed at the compiler driver side as that is the usual place to tune >> these things. We can ask users to specify -Wl,-Ttext-segment= (with lld >> use --image-base= instead) . >With the above approach we will have to target each and individual >application/library that is statically compiled. Sometimes the opposite. With tunable TEXT_START_ADDR you will need to ensure every user targeting your platform use the value. It's inconvenient for users who want to use a generic toolchain instead of a customized one. The emerging popularity of Clang in some part is it somewhat discourages such configure-time tuning. >> If that is inconvenient, with Clang you can >> add the option to a configuration file >> (https://clang.llvm.org/docs/UsersManual.html#configuration-files). >> With GCC there may be an option to add a fragment to the default specs >> file. >I'm more specifically concerned about yocto/debian builds which use >GCC. With the proposed approach the changes are central and we can >make sure everything will fall in place for yocto/debian rootfs builds >with a single change. > >Also what I get from Palmer is that moving forward we want to adjust >the TEXT_START_ADDR based on the page size (Huge page). I think GCC provides a way to customize its specs file. If 0x10000 is not a good value, I suggest just changing it to 0x200000 (lld aarch64/x86) or 0x400000 (ld.bfd aarch64/x86). Do not provide a customization