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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 0818F27C8D for ; Sat, 3 Aug 2024 04:03:22 +0200 (CEST) Received: (qmail 21950 invoked by uid 550); 3 Aug 2024 02:03:16 -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 21912 invoked from network); 3 Aug 2024 02:03:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexrp.com; s=alexrp; t=1722650589; x=1723255389; darn=lists.openwall.com; 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=QnOVDyXDkTABUzxtTiut00pDrXPMBB2z1FwY6/RWZDk=; b=Gu0hPTeQTnYmHt3qpGG+vGKfjfKhdpiD+N4giTBonO7AIyhEwr/y5KR7r8U4bugT2b uKdlpi+mGgv6LPNCPQhPWb0DJwJ9zrJs+JltzLCmuWPSzpa9v9MQiYsRRZY6tDATXCVK sXkKqhzTJpozAYW7+JIgulpSzdQDGPT6ckln6vGDZUEh4KTwm3h/P1Qb0qw153Yr19Kw rXbaZ6YvYKkNhaqGLkC1JWOABk2dK/DE8qQNkwqc2CjUyveTC2VdkIh/o23c2DCgEFAS 8TjgRCiz1/ZTwgultK2hSoorlTmT3awwzDuMEOyHy9B/6eZAzuC+jYVgXOXpYM8BgTbP DadA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722650589; x=1723255389; 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=QnOVDyXDkTABUzxtTiut00pDrXPMBB2z1FwY6/RWZDk=; b=pBrpOOgkq6R2r7MvWLGk9UoEWFtBvuKLWCkvQXVZmEUcXtOsiY3MhskvnjLkbljyLe 48DnCVKP9WpVH+isg3DqrKu8IAj5H9XBCLqRxzF3dJ0YdFoLDLezWV/7GUcWFLfhN9wy P6Tr2oHElgIQ/p9WjtvexaoRZenaIR6bdhc+jVDd2a3ceHxsCYmgUUaQ7iXZDW5kw1Xr NSiyAHcgGHjbIIkr2vPVt8sN/FRV3geq6GkXSuewYjKseH4OfVckJADEGcgRhuJXnVZu jQVzPD7DuvDa8jrm/aVa3DIWWYaxpfGDk3SAuHyJJBODDsIOymyZ59S+etnL+ugfptDl MRWQ== X-Gm-Message-State: AOJu0YwVE0NBwxy9ggHsv5n04PC/DKFAE4REpoERt/1GRQyI4ibj8xNd 3gE2kYEOt5UjbgBmtwxpwaXL42U0nWRUoMhcpoyUnU18otIHtqmlQdlzK42k5xDk3x+Z/JcT9gz y1/8EZe+60/wCqce47wsKvMItkhbyShS7r3Eb+DYoYIBJx8bK X-Google-Smtp-Source: AGHT+IGjZ8l3rW7uTxgSP20stfaO5AjoobSqAJIS1ZgrclSKtr0+1DoiWLYPlNgMv8/jgATk/U28LY0+DhfG86AaG/M= X-Received: by 2002:a05:600c:a0b:b0:427:d8f2:5dee with SMTP id 5b1f17b1804b1-428e6b00661mr34212385e9.15.1722650588695; Fri, 02 Aug 2024 19:03:08 -0700 (PDT) MIME-Version: 1.0 References: <20240629020434.488975-1-alex@alexrp.com> <20240723212241.GV3766212@port70.net> <20240723225853.GV10433@brightrain.aerifal.cx> <20240723232211.GX10433@brightrain.aerifal.cx> <20240724001312.GB10433@brightrain.aerifal.cx> In-Reply-To: <20240724001312.GB10433@brightrain.aerifal.cx> From: =?UTF-8?Q?Alex_R=C3=B8nne_Petersen?= Date: Sat, 3 Aug 2024 04:02:31 +0200 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] riscv: Fix setjmp assembly when compiling for ilp32f/lp64f. On Wed, Jul 24, 2024 at 2:13=E2=80=AFAM Rich Felker wrote= : > > On Wed, Jul 24, 2024 at 02:09:01AM +0200, Alex R=C3=B8nne Petersen wrote: > > On Wed, Jul 24, 2024 at 1:22=E2=80=AFAM Rich Felker w= rote: > > > > > > On Wed, Jul 24, 2024 at 01:12:33AM +0200, Alex R=C3=B8nne Petersen wr= ote: > > > > On Wed, Jul 24, 2024 at 12:58=E2=80=AFAM Rich Felker wrote: > > > > > > > > > > On Wed, Jul 24, 2024 at 12:47:14AM +0200, Alex R=C3=B8nne Peterse= n wrote: > > > > > > On Tue, Jul 23, 2024 at 11:22=E2=80=AFPM Szabolcs Nagy wrote: > > > > > > > > > > > > > > * Alex R=C3=B8nne Petersen [2024-06-29 04:0= 4:34 +0200]: > > > > > > > > To keep things simple, I just changed the instruction mnemo= nics appropriately, > > > > > > > > rather than adding complexity by changing the buffer size/o= ffsets based on ABI. > > > > > > > > > > > > > > > > Signed-off-by: Alex R=C3=B8nne 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 t= arget > > > > > > CPU. This is semantically distinct from `__riscv_float_abi`. Fo= r > > > > > > example, while it would probably be a bit silly, there's no par= ticular > > > > > > reason why I couldn't target the LP64F ABI on an RV64IMAFDC mac= hine.. > > > > > > In that case, no code needs to concern itself with the upper bi= ts of > > > > > > the FP registers. > > > > > > > > > > > > I took a quick peek at some of the `__riscv_flen` checks in mus= l. They > > > > > > look ok. They're checking the capabilities of the machine for t= he > > > > > > 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=3Drv64...d`, it would theoretically be fine for th= e > > > > > > 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 ma= chine > > > > > 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-b= it > > > > > registers (respectively), but the calling application could be bu= ilt > > > > > 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 particip= ate > > > > > in the calling convention? If so, no #ifdef is sufficient and the= re > > > > > must be a runtime hwcap check here to determine which form of > > > > > save/restore to do, like on arm and powerpc. > > > > > > > > I don't think this is a scenario that the ABI considers to be > > > > supported. If you try to link code of different ABIs, you will get > > > > linker errors such as: > > > > > > > > /tmp/ccz2Y86f.o: can't link soft-float modules with double-floa= t modules > > > > > > > > or > > > > > > > > /tmp/cc7rTh7R.o: can't link single-float modules with double-fl= oat modules > > > > > > Those are different ABIs. You can't link modules with mismatched ABI, > > > but you should be able to link modules that are both using -sf ABI (o= r > > > both using -sp ABI), where one is not using the fpu and the other is > > > using the full double fpu but only passing args in GPRs to conform > > > with the ABI. If that's not allowed, I would consider it a tooling > > > bug; there's no compatibility-constraint reason it can't be allowed. > > > > Oh, of course. I misread your question, sorry. > > > > Here's, I think, the relevant section of the calling convention: > > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-= cc.adoc#floating-point-register-convention > > > > This part is a bit awkward (to me, at least): > > > > Floating-point values in callee-saved registers are only preserved > > across calls if they are no larger than the width of a floating-point > > register in the targeted ABI. Therefore, these registers can always be > > considered temporaries if targeting the base integer calling > > convention. > > > > I'm not really sure why they're talking about "values" there; I would > > think the register width (in the machine vs the ABI) is the only thing > > we're concerned about in this context. I'm assuming that what they > > mean is: > > > > Floating-point registers in the callee-saved set are only > > preserved across calls if they are no larger than the width of a > > floating-point register in the targeted ABI. > > OK, perfect. That means we only need to decide what to save based on > the ABI, not dynamic hwcap or FPU capabilities. Does that mean the patch is fine as-is, or are there any adjustments I should make?