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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 5864924199 for ; Wed, 24 Jul 2024 02:09:50 +0200 (CEST) Received: (qmail 17482 invoked by uid 550); 24 Jul 2024 00:09:45 -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 17438 invoked from network); 24 Jul 2024 00:09:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexrp.com; s=alexrp; t=1721779777; x=1722384577; 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=i53+jG+fXsdmPxBbtpfSUYscwgB8uLgb2/s0L4Hbecw=; b=WO9ezhASLnagZsApc0Zf6oqeUQt6KWMNQJpUaZUMn1xI/UFwsrNSGasyyTysvb2hTa n/4MvE4JUkBadp5M+CTRE/wMjjtrhaG1fNoI6fnlxy9Bt5guXq2WsGj/JItGJQb0Jjci 5mQ8p6dbWEtNyTQi2aNqAh24tP7m3wnX0oFF6kOleGnMjNVeEJ4BlSxjhCYMTumN1y9n 8ebOzVN/QsoWgQzXK000svEb3XL4OY+ldeZeh8KpuLg4uHPkltbLgS5jXSasWfsH555a 8PB4Qsh19sBTzzLXeL7G0A0qWCmYGqvCsHtcujmhbAv6SMOICMkDHVRjB1tYPVbE6iIJ p/yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721779777; x=1722384577; 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=i53+jG+fXsdmPxBbtpfSUYscwgB8uLgb2/s0L4Hbecw=; b=Koog6tCrOlB559yIaW20Ur58ejU6gx1yctR9IJ2RMP2nNc2qUGtkCngA9ss3c1y0bd cjDFLF0P/iTcb2s9peFKQOoaaieNx9M/JXmFNiA+FYmKunZRRKE25hD4/70j38THtkbr p2tg6WbP8Sya8vpysC7mN8MK+MRtROmPVrY8PpwVO/GiMJJh9/BW4pRWVtnI+Ms+D6LM JCod6Q2cU3bcaLn4byrJiuhvMeOegGnj4bBrlAsHDjCpDKnx1nzGw/ddouUhGmH2B44U r0zJ5ncIRuxwEtixjY1VjZN7mgDBbLrl2ZLR/Pi0z71jhDYEIIbN0TDUr8ugGuriIG21 6KhQ== X-Gm-Message-State: AOJu0YzM6FSfodPhNXi71dSTimNg5LlhrVLHy6GILL2dc33nOsH2IPUp 8WVK8euO9gnwTmsYEUVKJe8CcxbOldOHeBYuZtz60oB3cLunugbfNfLqScLfimvLatykV8FPON1 aM8f8CYoYVxDiexfugrxzpm31jI88domyYPGhMwuQl3Ssk0WTvPg= X-Google-Smtp-Source: AGHT+IEMGL3d/EUzbCsDLs781Gs081zJoiarJM7C6mRhAdLLdxqZcvZBU6Kxjt7lH7gZQBA6u0zxY5yPXR70N9bC2Fk= X-Received: by 2002:a05:6000:1884:b0:368:5e34:4b4b with SMTP id ffacd0b85a97d-369f5b162b1mr302696f8f.6.1721779777393; Tue, 23 Jul 2024 17:09:37 -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> In-Reply-To: <20240723232211.GX10433@brightrain.aerifal.cx> From: =?UTF-8?Q?Alex_R=C3=B8nne_Petersen?= Date: Wed, 24 Jul 2024 02:09:01 +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 1:22=E2=80=AFAM Rich Felker wrote= : > > On Wed, Jul 24, 2024 at 01:12:33AM +0200, Alex R=C3=B8nne Petersen wrote: > > 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 Petersen wr= ote: > > > > On Tue, Jul 23, 2024 at 11:22=E2=80=AFPM Szabolcs Nagy wrote: > > > > > > > > > > * Alex R=C3=B8nne 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/offse= ts 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 targe= t > > > > CPU. This is semantically distinct from `__riscv_float_abi`. For > > > > example, while it would probably be a bit silly, there's no particu= lar > > > > 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 o= f > > > > the FP registers. > > > > > > > > I took a quick peek at some of the `__riscv_flen` checks in musl. T= hey > > > > 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=3Drv64...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 LP6= 4F > > > > rules. > > > > > > If you're building code for -sf or -sp ABI, but could run on a machin= e > > > 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. > > > > 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-float mo= dules > > > > or > > > > /tmp/cc7rTh7R.o: can't link single-float modules with double-float = 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 (or > 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.a= doc#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.