From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id C46703858CDA for ; Tue, 29 Nov 2022 19:35:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C46703858CDA 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-pf1-x435.google.com with SMTP id w79so14697490pfc.2 for ; Tue, 29 Nov 2022 11:35:45 -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=jeNLKahm+Am4JitgBj5bDl+MD2j2cYUsQaMLMrRxdls=; b=lf5UF//via5hAuw5nJTea573oTAxuhWoLW8Xnv6RgNlICEOxR/f3wTb44Yd/FyOiGH 3ksl/fs4063vcHHXr+2WXy1DAT5OLb/d5iuORaHelsNPAZSPjYL2Mi/DFgMW19kURdbN ryEZP7tilrREc7bwCyHJN0f1jTgo731i4m3TGFsV4Y+QhEcurVHOf8+6X5FA3lihX0Pe e9/8SpO6WBskn2fdYmJYXPH2kbT/JXV1CKbWS9UD1WWrDnodAZJxupGH7d3PTL3MgP/N gFRqQL2XttqQfgEA7Kmex2dPswIgBcx2PJtIhEnvDZ3eSRC+15pVAJ2DP+EibB7i5Ytv Hd0w== 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=jeNLKahm+Am4JitgBj5bDl+MD2j2cYUsQaMLMrRxdls=; b=7boyH3bMW+M09uhfnKoMLA+DWAnPpZCmFtKydndWfhgaB/rM5pumXRn6skemA6HgOC 3S2s/LmIL0wQ83jETlsXE5nHOUOIM/ZWFDcbh6e+9MNmbPBMHNKW7Wn04EF9TLt487MI QmG/rtn2ERnxW28X/QUD8CYG0z3F2Bdkbiq9mvco8xRf/23wVtYWw+yTlCy11qQT2hAV P3d3OK8QlwiLwB7dnwuKUhrzgaHsR8WJL+OSytcIb92ll7GC6qFyCw//vpkNHMY52zuV /RrTqe/C626qroM6WrrJYDRBT5h8L1lSnQ/DYB0R/87rYzADrPLSi2UiOSf0/dh6DSBw s4bQ== X-Gm-Message-State: ANoB5pksvrs2IYX3S9Yq2Gbaqgb6Ei3hvCUuKAmUEw6LM1mk8cqsaCJh TceXLBZTmvK2s3O2+nMh/Dfxz8mPgf/4CA== X-Google-Smtp-Source: AA0mqf49DxGKzuKOBJZvTLj9WYNEswvNMnFtDsF9yIjrVj8vvQAAzkvWlTEbV218qkjAAZ2eZeFobg== X-Received: by 2002:a62:6205:0:b0:56c:14a5:2245 with SMTP id w5-20020a626205000000b0056c14a52245mr38471012pfb.12.1669750544170; Tue, 29 Nov 2022 11:35:44 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id f30-20020a631f1e000000b004351358f056sm8719174pgf.85.2022.11.29.11.35.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 11:35:43 -0800 (PST) Date: Tue, 29 Nov 2022 11:35:43 -0800 (PST) X-Google-Original-Date: Tue, 29 Nov 2022 11:35:33 PST (-0800) Subject: Re: [QUERY]: Adding support for a platform In-Reply-To: CC: binutils@sourceware.org, linux-riscv@lists.infradead.org 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=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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 Tue, 29 Nov 2022 11:28:11 PST (-0800), prabhakar.csengg@gmail.com wrote: > Hi Palmer, > > Oops I should have included linux-riscv to the CC list here (doing it now) > > On Tue, Nov 29, 2022 at 7:20 PM Palmer Dabbelt wrote: >> >> On Tue, 29 Nov 2022 11:16:29 PST (-0800), binutils@sourceware.org wrote: >> > Hi All, >> > >> > If this is not the right place to ask this question please let me know. >> > >> > 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 cause >> 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 0x0000000000010000 > 0x0000000000059b48 0x0000000000059b48 R E 0x1000 > LOAD 0x0000000000059b60 0x000000000006ab60 0x000000000006ab60 > 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’0_0003_0000 - H’0_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’0_0003_0000 - H’0_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 0x0000000000050000 > 0x0000000000057dc8 0x0000000000057dc8 R E 0x1000 > LOAD 0x00000000000585b8 0x00000000000a95b8 0x00000000000a95b8 > 0x0000000000004ee0 0x00000000000064b0 RW 0x1000 > NOTE 0x0000000000000158 0x0000000000050158 0x0000000000050158 > 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. 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. 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). > Cheers, > Prabhakar