From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id A33203858D1E for ; Wed, 21 Dec 2022 20:06:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A33203858D1E 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-ej1-x632.google.com with SMTP id u19so103910ejm.8 for ; Wed, 21 Dec 2022 12:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GaJWgHm8yLSOiD11gzsSMfzkld+WD6ww8FKryoFgcH8=; b=IcQVAK/TSVJVr6JUlOg8gfeASPhi09LzE3AbQDPAQ7PfnwxcQTFKBT3Z7l6Zy89kYI iG0DGoq9OoPSf/mwKu8AcltLQeor85XaFSZh4fIGxP0F1/rQuUB+3L7sPLIxPPNuChfA L2a8ZrkQ1aGkGffuK3xO79veIvtFY7q27+qXv154ThKGgM+jUlMJfk2YVKod4KEuy9TT IHv7lDDY51JVn9iOsKwZjXZ5bWz1/s/1grubmz4LHT0qJZ7jo7/qrIa4UhHbzlNgVYJq PI1ithBnVk2Sqy9ixu3Odz3QeOEegZElWFVlSZ58rzliEd+UYFFfEmm5z/yq9vCiwVnU A7dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GaJWgHm8yLSOiD11gzsSMfzkld+WD6ww8FKryoFgcH8=; b=OrlyVvYBpIlf+7CE9HTXzw7lx6aNU5i2m+A960obrI87YswPPG6Hcmx7N1GamIfzIk 2yFHXGhDJO8Pawn3PkcXO3+PZ/gDtcNWM/RjLxwJPAcYlDgfcg78D2Un1k20a6MEiIsf 2mAYu5O8XvqBiieUsxaCaHy0M0KTDq0KO2wFv481cjuK04G13WYeq3doUBH98QOzodGP 74oy3klw8ZDWlqg6X81Jb8lGAvbt/fpOIWkk/2sOg+OxZZDFqx48IfAfVmCJZEzlWd/C 6BkDBSFuIKxZYFE7M7XHUlvf4n8ZUqQ/QZvL0HKgYkDz00tzKT42gnAKXHiw4Gb8g7UT 4FwQ== X-Gm-Message-State: AFqh2kok0nhepaQ5T5YIOL8/7PUts+ra5K4sCFI8nPATOZFEYraQ3ULL QgumJq7iPoQS1nmziaJL6YE5GcouZHII0OHNuiY= X-Google-Smtp-Source: AMrXdXv74bS4eoplg0C4jJXPvEhHgVnME0Hxw4eza9OBOdrUfUemhMpBkwHbGTsoxCuSI6c3Yhn5OtTdGnKOI0l5lY0= X-Received: by 2002:a17:907:d601:b0:78d:bc9f:33da with SMTP id wd1-20020a170907d60100b0078dbc9f33damr237476ejc.80.1671653201322; Wed, 21 Dec 2022 12:06:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Lad, Prabhakar" Date: Wed, 21 Dec 2022 20:06:14 +0000 Message-ID: Subject: Re: [RFC PATCH] ld/emulparams: elf32lriscv-defs: Add support tune the text segment start address To: Palmer Dabbelt Cc: jeffreyalaw@gmail.com, i@maskray.me, prabhakar.mahadev-lad.rj@bp.renesas.com, Andrew Waterman , Jim Wilson , nelson@rivosinc.com, binutils@sourceware.org, Chris.Paterson2@renesas.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,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: Hi Palmer, Thank you for the feedback. On Mon, Dec 19, 2022 at 9:33 PM Palmer Dabbelt wrote: > > On Mon, 19 Dec 2022 01:11:13 PST (-0800), prabhakar.csengg@gmail.com wrote: > > Hi Jeff, > > > > On Mon, Dec 19, 2022 at 5:00 AM Jeff Law wrote: > >> > >> > >> > >> On 12/18/22 15:44, Lad, Prabhakar via Binutils 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 > > I'm never great with shell expansion, what does the "+x" do here? > where ${DEFAULT_TEXT_START_ADDR+x} is a parameter expansion which evaluates to nothing if var is unset, and substitutes the string x otherwise > I'm also not sure how this is meant to be used/set, is there some > autoconf changes that this needs to come along with so this can be set? > There is no autoconf for this, so when trying to build with a different offset we just export DEFAULT_TEXT_START_ADDR in the shell with a value and then build it. So for example when trying to build from Yocto we just bbappend the binutils file and export the DEFAULT_TEXT_START_ADDR variable. > >> >>> + 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. > >> > > >> >> 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). > >> Another approach here is to consider this system independent of the > >> other risc-v platforms and give it its own emulation template rather > >> than polluting the generic risc-v template with this issue. > >> > > Sounds good to me, For example it would include the RISC-V generic > > template and we just override the offset in the platform specific conf > > file. Having said that, I'm not sure of the maintainability of such > > files and RISC-V maintainers will be OK for such change. > > I was assuming we'd have a configure option somewhere in the toolchain > to control the default. I hadn't really thought of where, either > binutils or GCC could make sense (as it's driven by a `-Wl` option). I > haven't quite sorted out how this modification to ldparams does that (as > above). > > That said, maybe the right answer here is actually to just have > "-mcpu=renesas-rzfve" just include -Ttext-segement= in LINK_SPEC? So that means we want GCC to accept "renesas-rzfive" as an mcpu option and then we update LINK_SPEC [0] based on the mcpu parameter. [0] https://github.com/gcc-mirror/gcc/blob/releases/gcc-9/gcc/config/riscv/linux.h#L60 Is my understanding correct here? > if we implement the Linux side of this as "don't mmap() unless the hint says > to, and then context switch the memory" then it's essentially just a CPU > tuning parameter (with a giant security hole, but nothing we can do > about that). > I'm not sure how maintainers will react to this if we propose a solution. I wonder if we are just alone with such a problem. > > I'm curious what Palmer has in his mind on tuning this parameter for > > huge pages. If that exposes some sort of config option we could use > > that option to set the offset. > > The hugepage thing might not be all that exiciting: it's just a question > of whether we're defaulting to 2nd-level or 3rd-level paging. Having > the default as-is for 2nd-level paging seems reasonable as it gives a > lot more range for symbols, so maybe nobody even wants to default to the > 3rd-level offsets. > Okay, so I won't play the huge page card ;) Cheers, Prabhakar