From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 1296B233E8 for ; Wed, 24 Jul 2024 00:59:07 +0200 (CEST) Received: (qmail 17638 invoked by uid 550); 23 Jul 2024 22:59:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17591 invoked from network); 23 Jul 2024 22:59:01 -0000 Date: Tue, 23 Jul 2024 18:58:54 -0400 From: Rich Felker To: Alex =?utf-8?B?UsO4bm5l?= Petersen Cc: musl@lists.openwall.com Message-ID: <20240723225853.GV10433@brightrain.aerifal.cx> References: <20240629020434.488975-1-alex@alexrp.com> <20240723212241.GV3766212@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] riscv: Fix setjmp assembly when compiling for ilp32f/lp64f. On Wed, Jul 24, 2024 at 12:47:14AM +0200, Alex Rønne Petersen wrote: > On Tue, Jul 23, 2024 at 11:22 PM Szabolcs Nagy wrote: > > > > * Alex Rønne Petersen [2024-06-29 04:04:34 +0200]: > > > To keep things simple, I just changed the instruction mnemonics appropriately, > > > rather than adding complexity by changing the buffer size/offsets based on ABI. > > > > > > Signed-off-by: Alex Rønne Petersen > > > > fwiw this looks good to me. > > > > the only weirdness is that the math code uses __riscv_flen > > and this code __riscv_float_abi*. i don't know if there > > is semantic difference. > > `__riscv_flen` tells you the width of the FP registers on the target > CPU. This is semantically distinct from `__riscv_float_abi`. For > example, while it would probably be a bit silly, there's no particular > reason why I couldn't target the LP64F ABI on an RV64IMAFDC machine. > In that case, no code needs to concern itself with the upper bits of > the FP registers. > > I took a quick peek at some of the `__riscv_flen` checks in musl. They > look ok. They're checking the capabilities of the machine for the > purposes of performing a computation; they're not making ABI > decisions. In my silly example above, if I tell the compiler to do so > with `-march=rv64...d`, it would theoretically be fine for the > compiler to generate double-precision float instructions for > computations as long as values are passed/returned according to LP64F > rules. If you're building code for -sf or -sp ABI, but could run on a machine with larger floating point register file, it's possible that the user could have libc built not to use fp registers at all or only 32-bit registers (respectively), but the calling application could be built for and running on a machine with 64-bit registers. In this case we need to understand what the ABI says. Are the 64-bit register, if present, call-saved in lower ABI levels where they don't participate in the calling convention? If so, no #ifdef is sufficient and there must be a runtime hwcap check here to determine which form of save/restore to do, like on arm and powerpc. Rich