grovel/src/setjmp, branch main

Fix the build system.

2024-01-05T08:43:22Z

The improvements are: - use most of the default "Makefile" for standard packaging; - also use the default ".gitignore" with for the derived assets; - don't impose so many $CFLAGS on the user. GCC still needs to be given the `-ffreestanding` flag explicitly for us to get a good binary; - stop using ad-hoc tools/* scripts, and avoid the code-generation anti-pattern overall on the build. Some of the generated files were checked-in, and some were removed; - remove empty files; - use POSIX make(1) over gmake; - add fuzz targets; - partial "install" and "uninstall" targets; - complete "clean" target. The shortcomings are: - only working on x86_64. More platforms coming soon; - code is still messy: way too many warnings, GNU/BSD specific extensions, inline assembly, and all kinds of unportable code; - still only works with GCC and GCC-like compilers, and completly fails with tcc(1) and cproc(1); - the `deps.mk` file is being maintained manually. As I work on the source files I'll finish automating its generation with `mkdeps.sh`; - still seems to be coupled with Linux; - still is missing tests setup; - still uses `#include <$NAME.h>` instead of the correct `#include "$NAME.h"` form. The generated libgrovel.a did match the previous lib/libc.a 100%.

powerpc-sf longjmp clobbering of val argument

2023-02-11T15:00:31Z

the logic to check hwcap for SPE register file inadvertently clobbered the val argument before use. switch to a different work register so this doesn't happen.

fix hwcap access in powerpc-sf setjmp/longjmp

2021-11-29T22:41:43Z

commit 7be59733d71ada3a32a98622507399253f1d5e48 introduced the hwcap-based branches to support the SPE FPU, but wrongly coded them as bitwise tests on the computed address of __hwcap, not a value loaded from that address. replace the add with indexed load to fix it.

add SPE FPU support to powerpc-sf

2021-09-23T23:11:46Z

When the soft-float ABI for PowerPC was added in commit 5a92dd95c77cee81755f1a441ae0b71e3ae2bcdb, with Freescale cpus using the alternative SPE FPU as the main use case, it was noted that we could probably support hard float on them, but that it would involve determining some difficult ABI constraints. This commit is the completion of that work. The Power-Arch-32 ABI supplement defines the ABI profiles, and indeed ATR-SPE is built on ATR-SOFT-FLOAT. But setjmp/longjmp compatibility are problematic for the same reason they're problematic on ARM, where optional float-related parts of the register file are "call-saved if present". This requires testing __hwcap, which is now done. In keeping with the existing powerpc-sf subarch definition, which did not have fenv, the fenv macros are not defined for SPE and the SPEFSCR control register is left (and assumed to start in) the default mode.

aarch64: fix setjmp return value

2020-08-13T01:53:25Z

longjmp should set the return value of setjmp, but 64bit registers were used for the 0 check while the type is int. use the code that gcc generates for return val ? val : 1;

setjmp: optimize longjmp prologues

2020-08-13T01:52:56Z

Use a branchless sequence that is one byte shorter on 64-bit, same size on 32-bit. Thanks to Pete Cawley for suggesting this variant.

setjmp: optimize x86 longjmp epilogues

2020-08-11T18:43:20Z

setjmp: avoid useless REX-prefix on xor %eax, %eax

2020-08-11T18:43:12Z

setjmp: fix x86-64 longjmp argument adjustment

2020-08-11T18:42:54Z

longjmp 'val' argument is an int, but the assembly is referencing 64-bit registers as if the argument was a long, or the caller was responsible for extending the argument. Though the psABI is not clear on this, the interpretation in GCC is that high bits may be arbitrary and the callee is responsible for sign/zero-extending the value as needed (likewise for return values: callers must anticipate that high bits may be garbage). Therefore testing %rax is a functional bug: setjmp would wrongly return zero if longjmp was called with val==0, but high bits of %rsi happened to be non-zero. Rewrite the prologue to refer to 32-bit registers. In passing, change 'test' to use %rsi, as there's no advantage to using %rax and the new form is cheaper on processors that do not perform move elimination.

fix mips setjmp/longjmp fpu state on r6, related issues

2019-09-27T03:46:09Z

mips32 has two fpu register file variants: FR=0 with 32 32-bit registers, where pairs of neighboring even/odd registers are used to represent doubles, and FR=1 with 32 64-bit registers, each of which can store a single or double. up through r5 (our "mips" arch), the supported ABI uses FR=0, but modern compilers generate "fpxx" model code that can safely operate with either model. r6, which is an incompatible but similar ISA, drops FR=0 and only provides the FR=1 model. as such, setjmp and longjmp, which depended on being able to save and restore call-saved doubles by storing and loading their 32-bit halves, were completely broken in the presence of floating point code on mips r6. to fix this, use the s.d and l.d mnemonics to store and load fpu registers. these expand to the existing swc1 and lwc1 instructions for pairs of 32-bit fpu registers on mips1, but on mips2 and later they translate directly to the 64-bit sdc1 and ldc1. with FR=0, sdc1 and ldc1 behave just like the pairs of swc1 and lwc1 instructions they replace, storing or loading the even/odd pair of fpu registers that can be treated as separate single-precision floats or as a unit representing a double. but with FR=1, they store/load individual 64-bit registers. this yields the ABI-correct behavior on mips r6, and should make linking of pre-r6 (plain "mips") code with "fp64" model code workable, although this is and will likely remain unsupported usage. in addition to the mips r6 problem this change fixes, reportedly clang's internal assembler refuses to assemble swc1 and lwc1 instructions for odd register indices when building for "fpxx" model (the default). this caused setjmp and longjmp not to build. by using the s.d and l.d forms, this problem is avoided too. as a bonus, code size is reduced everywhere but mips1.