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;
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.
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.
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.
armv8 removed the coprocessor instructions other than cp14, so on an armv8 system the related hwcaps should never be set. new llvm complains about the use of coprocessor instructions in armv8-a mode (even though they are never executed at runtime), so ifdef them out when musl is built for armv8.
Author: Alex Suykov <alex.suykov@gmail.com> Author: Aric Belsito <lluixhi@gmail.com> Author: Drew DeVault <sir@cmpwn.com> Author: Michael Clark <mjc@sifive.com> Author: Michael Forney <mforney@mforney.org> Author: Stefan O'Rear <sorear2@gmail.com> This port has involved the work of many people over several years. I have tried to ensure that everyone with substantial contributions has been credited above; if any omissions are found they will be noted later in an update to the authors/contributors list in the COPYRIGHT file. The version committed here comes from the riscv/riscv-musl repo's commit 3fe7e2c75df78eef42dcdc352a55757729f451e2, with minor changes by me for issues found during final review: - a_ll/a_sc atomics are removed (according to the ISA spec, lr/sc are not safe to use in separate inline asm fragments) - a_cas[_p] is fixed to be a memory barrier - the call from the _start assembly into the C part of crt1/ldso is changed to allow for the possibility that the linker does not place them nearby each other. - DTP_OFFSET is defined correctly so that local-dynamic TLS works - reloc.h LDSO_ARCH logic is simplified and made explicit. - unused, non-functional crti/n asm files are removed. - an empty .sdata section is added to crt1 so that the __global_pointer reference is resolvable. - indentation style errors in some asm files are fixed.
three ABIs are supported: the default with 68881 80-bit fpu format and results returned in floating point registers, softfloat-only with the same format, and coldfire fpu with IEEE single/double only. only the first is tested at all, and only under qemu which has fpu emulation bugs. basic functionality smoke tests have been performed for the most common arch-specific breakage via libc-test and qemu user-level emulation. some sysvipc failures remain, but are shared with other big endian archs and will be fixed separately.
this is a subtle issue with how the assembler/linker work. for the adr pseudo-instruction used to find __hwcap, the assembler in thumb mode generates a 16-bit thumb add instruction which can only represent word-aligned addresses, despite not knowing the alignment of the label. if the setjmp function is assigned a non-multiple-of-4 address at link time, the load then loads from the wrong address (the last instruction rather than the data containing the offset) and ends up reading nonsense instead of the value of __hwcap. this in turn causes the checks for floating-point/vector register sets (e.g. IWMMX) to evaluate incorrectly, crashing when setjmp/longjmp try to save/restore those registers. fix based on bug report by Felix Hädicke.