[Bug 268684] [PATCH] riscv libc: fix longjmp with 0 value
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 268684] riscv libc: fix longjmp with 0 value"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 268684] riscv libc: fix longjmp with 0 value"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 268684] riscv libc: fix longjmp with 0 value"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 31 Dec 2022 19:38:25 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268684
Bug ID: 268684
Summary: [PATCH] riscv libc: fix longjmp with 0 value
Product: Base System
Version: CURRENT
Hardware: riscv
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: riscv
Assignee: riscv@FreeBSD.org
Reporter: alois+freebsd@aloisklink.com
Created attachment 239166
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239166&action=edit
`git format-patch` patch file
On RISC-V, calling `longjmp(x, 0);` makes `setjmp(x)` return 0, which normally
causes an infinite loop, and is against the ISO C standard for setjmp/longjmp.
Instead, using a value of 0 should make `setjmp` return 1:
> The `longjmp` function cannot cause the `setjmp` macro to return the
> value 0; if `val` is 0, the `setjmp` macro returns the value 1.
>
> _Taken from ยง7.13.2.1.4 of the C99 spec_
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268521 for my similar
patch for arm64 libc. That patch also has a test-case that I used to test this
RISC-V implementation.
---
I think I've actually managed to beat the compiler in this patch.
Both GCC and Clang do something like the following at `-Os`:
```Assembly
mv a0,a1
bne a1,zero,.L2
li a0,1
.L2:
ret
```
It took a while of scouring the RISC-V ISA spec (it's my first time using
RISC-V assembly), but I found a method that doesn't use branching and has less
one less instruction!
--
You are receiving this mail because:
You are the assignee for the bug.