From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 0CB603858D35 for ; Tue, 29 Nov 2022 21:34:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0CB603858D35 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-x62b.google.com with SMTP id vv4so36981884ejc.2 for ; Tue, 29 Nov 2022 13:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=raxsiOTJycWUQMgi+7NyFe4tBvg9owbpLglKenp5iLs=; b=gu68Dlmxv+6CrUzWo6Ne5JDly3z0O5Kp5y58oUKFCSJ7u4Fj5bE/OnAY25uFDWjXd1 Dq7dDr+IQZ4wsjAedWVCyq+yXqjwq2PM85GzzL8ZQc6tFEcz3pPjLfK98eLv3WFhnzyZ tDQuvhFL1gLnsQysU6LpqzZOU8O/MmJUydLLN97n3OdUdagwAD/wueqc1G6Am0iCSnqb jmbpRQDvRM3V6nktqcBXuY+MuFaoiwWDcvm2M3u7zlrFLuBnttpvvpEcVS/pwPxn0gXZ iN/DmuEq3r0jCmR/pobKxhtXRvrSDyF7AXrQJGGNa7EQ2L886PIdMVbAQglR5E5iTlSl ypYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=raxsiOTJycWUQMgi+7NyFe4tBvg9owbpLglKenp5iLs=; b=LJ64iC09nDqgJ1eZXZMnjbeImY8gAcj+VM3sa1R5ZfISnanPl9zWmQRQNfBnaW9ZYq uc9fxiBEo9FclHSyoP0MR4+2knDXpzq6yqDVdC0p0jPD5rbYyh0wCzqImV+oR8rT9MuN IeiNT++PK4PvmtPMZcc5yWahdtTbAiZBfDuk5/gt3+5KA27C5MucZxrjHUM7IUpRuwMM E1dasO3sxeFSMRG8tWqkmv9xLl6Hl1Nzde2GjwEIkaBG+3AUg86QxbFKM5LcKE4Bf5Wg tiLu+WFjRID2cM3a7YwHkwMJUZ2bP08yIcrDT9gesXLTTlMyAcEVjvM8lBxJH4b23Sq1 6Org== X-Gm-Message-State: ANoB5pkWDgUyX6RnSJe+yJ0hFLpiiuC1eUgSwlqooROML3JSpdmggFyf VdWlqnaZ1cgWCmr6ARvyRHsvwDL7ZLvqn/MNe5T3DV9QGs8= X-Google-Smtp-Source: AA0mqf7Yy2q+g1+sVprQFzrzAXUGK2m5V7Iyl6GHrP2GApdErE+G5Mh2eX/ZfwAyDKTBxkvwIwG2/LWwbuBcFQnqzPE= X-Received: by 2002:a17:906:3e41:b0:78d:bc9f:33da with SMTP id t1-20020a1709063e4100b0078dbc9f33damr48432104eji.80.1669757660776; Tue, 29 Nov 2022 13:34:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Lad, Prabhakar" Date: Tue, 29 Nov 2022 21:33:54 +0000 Message-ID: Subject: Re: [QUERY]: Adding support for a platform To: Palmer Dabbelt Cc: binutils@sourceware.org, linux-riscv@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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, On Tue, Nov 29, 2022 at 7:35 PM Palmer Dabbelt wrote: > > On Tue, 29 Nov 2022 11:28:11 PST (-0800), prabhakar.csengg@gmail.com wrot= e: > > Hi Palmer, > > > > Oops I should have included linux-riscv to the CC list here (doing it n= ow) > > > > On Tue, Nov 29, 2022 at 7:20 PM Palmer Dabbelt wro= te: > >> > >> On Tue, 29 Nov 2022 11:16:29 PST (-0800), binutils@sourceware.org wrot= e: > >> > Hi All, > >> > > >> > If this is not the right place to ask this question please let me kn= ow. > >> > > >> > So we have a RISCV platform (Renesas RZ/Five) for which we need to > >> > adjust the TEXT_START_ADDR. So below are my queries: > >> > * What is the procedure for upstreaming? > >> > * Are patches accepted for individual platforms (for adjusting TEXT_= START_ADDR)? > >> > >> Is this still related to that bug with the static binaries you'd > >> mentioned before? I think we'd really need to figure out the root cau= se > >> before we can make a reasoned decision here, my guess would be that > >> changing TEXT_START_ADDR just works around the real bug. > >> > > Below is the root cause and the solution: > > > > TEXT_START_ADDR is the start of the text segment of an application. > > This is being set to 0x10000 for RISCV platforms. > > > > So when an application is compiled with the static flag the load would > > start from 0x10000 - xyz (depending on size of the application) > > > > Entry point 0x101c0 > > There are 5 program headers, starting at offset 64Program Headers: > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flags Align > > LOAD 0x0000000000000000 0x0000000000010000 0x00000000000100= 00 > > 0x0000000000059b48 0x0000000000059b48 R E 0x1000 > > LOAD 0x0000000000059b60 0x000000000006ab60 0x000000000006ab= 60 > > 0x0000000000001f68 0x0000000000003528 RW 0x1000 > > > > So for the above application which is compiled statically we can see > > the entry point is 0x101c0 and load 0x0000000000010000. > > > > Andes AX45MP cores have local memory ILM and DLM that are mapped in > > the region H=E2=80=990_0003_0000 - H=E2=80=990_0004_FFFF on the RZ/Five= SoC. 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 hence > > the application fails to run (panics somewhere). > > > > So to avoid this issue we set the TEXT_START_ADDR to 0x50000 so that > > the virtual address of any statically compiled application does not > > fall in the range of H=E2=80=990_0003_0000 - H=E2=80=990_0004_FFFF. > > > > Elf file type is EXEC (Executable file) > > Entry point 0x504e4 > > There are 5 program headers, starting at offset 64 > > > > Program Headers: > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flags Align > > LOAD 0x0000000000000000 0x0000000000050000 0x00000000000500= 00 > > 0x0000000000057dc8 0x0000000000057dc8 R E 0x1000 > > LOAD 0x00000000000585b8 0x00000000000a95b8 0x00000000000a95= b8 > > 0x0000000000004ee0 0x00000000000064b0 RW 0x1000 > > NOTE 0x0000000000000158 0x0000000000050158 0x00000000000501= 58 > > 0x0000000000000044 0x0000000000000044 R 0x4 > > > > So now with the fix for statically compiled applications we can see > > its offsetted and entry point is 0x504e4 and load is at > > 0x0000000000050000. So with this we are for sure the MMU will always > > trigger a page fault. > > OK, cool, that explains it. > > So I think we need to teach Linux about this platform-specific behavior > so we can prevent any addresses in the offending VA range from being > allocated. Agreed, any pointers on doing this? > Then it'll be up to userspace to deal with the fallout, if > that means changing TEXT_START_ADDRESS it seems fine to me. I'm not > sure if there's already some sort of autoconf-type thing to change the > default in binutils, if not then adding one seems like the way to go. > TBH I haven't explored the code yet if it was configurable using autoconf. I'll have to do some digging. > Then it's up to distros that want to run on the impacted hardware to > make sure they rebuild all the impacted binaries. I don't think there's > any way around that for userspace-visible errata, and it this case the > check for impacted binaries seems pretty manageable to write down (some > sort of `find | objdump | grep` thing would probably do it). > Agreed. Cheers, Prabhakar