From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id A95583858D1E for ; Mon, 19 Dec 2022 21:33:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A95583858D1E 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-pl1-x631.google.com with SMTP id x2so10275327plb.13 for ; Mon, 19 Dec 2022 13:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; 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=XbgNPiDzpvu4UTskdTayRZBt0cIYZGxDJm4RlhiWr40=; b=J3T2UHgobCBl4HAC72o1bdt7izf4EBqU5zvywCYZsw2IkpFX6qMuM42+H7MNdHSrWm W8NwSZDFUvBLYzmFeTMbwKZZV58duVWOfDAb7gm3PDnF1p8LqAKbfUrR72Za3YDGgJOS XSRi413FnB1jCW7tv39Zyks2mYHgQzWX4BSJpTj2miGa0GyvoaXZyUV2ffRlDMcNI4t3 1KW3J9bq41U51K/nj1TaZHO+/CNkkpwHxT+bQAI2vT4+muZ8ZRhAIZhBdrIml8R0zAzz CqWUqvh1BaVUOvzyWsl6pXhk4ye8lMvzgRF3J1IfHCRHmUCGwk/qb+EbBDVbMM9pYxOE 6JaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=XbgNPiDzpvu4UTskdTayRZBt0cIYZGxDJm4RlhiWr40=; b=Gjb4XlWl9kFDyv14zA5U/gCOduKh2vz8awzA/auUisBXBLoO8tfYBuE0NPq9WdGIu6 CIKvx0PH6n2xIr9k1ibbZ6EqAVLUTfoKvto+RHf7qQ7fKYb/W0E8QyxUJk3ct4pSycDQ s7/fQh/b6BrlvUUnTlOH17hr674iR1hbnTRvESEstXlwgED19Vy1QfIKfNCpuUfG513s Kz1VQ7p3GVjs0Pf86ldOfZitxlEFHXCkZ6dBvDrvDdRZjkK8OHuXvSQ2hBhdzDdUcRMr fptPThuNPU7s3a6i70jLHY4HCl2yfNdNIc1U8sCd60AsbEhf1OCtzwaHRbyiJv7f69uw CCOw== X-Gm-Message-State: ANoB5pl2Tv2bFCa0zxDDzJCjFkIVXcJx1rcf1SSZB2blzjmuPGu3dRvK uUX/GmtVF/5nSETMK5ck84qQYSBXJhA5U/Yj X-Google-Smtp-Source: AA0mqf6QwGY/ScG6TsW8S5SgEiByqWPml9jTe+F/fbufSzPi/xSlQnkSia1U0bL2MXPsoeNiXufpCw== X-Received: by 2002:a17:903:22c3:b0:189:d92b:86e4 with SMTP id y3-20020a17090322c300b00189d92b86e4mr66325022plg.52.1671485588509; Mon, 19 Dec 2022 13:33:08 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id p8-20020a170902e74800b0018f6900a183sm7696396plf.140.2022.12.19.13.33.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Dec 2022 13:33:08 -0800 (PST) Date: Mon, 19 Dec 2022 13:33:08 -0800 (PST) X-Google-Original-Date: Mon, 19 Dec 2022 13:32:49 PST (-0800) Subject: Re: [RFC PATCH] ld/emulparams: elf32lriscv-defs: Add support tune the text segment start address In-Reply-To: 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 From: Palmer Dabbelt To: prabhakar.csengg@gmail.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=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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: 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? 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? >> >>> + 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? 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 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. >> I'm leery of including these bits in the generic risc-v code given it's >> really working around, umm, quirks, mis-features or whatever we might >> want to call them. >> > :-) I think we have way bigger pollution problems than this. > > Cheers, > Prabhakar