|
|
Message-Id: <43ebf0b3-1765-412a-9317-1c3787c550cf@app.fastmail.com> Date: Tue, 03 Nov 2026 13:56:48 +0100 From: "Imre Kaloz" <kaloz@...nel.org> To: "Szabolcs Nagy" <nsz@...t70.net> Cc: musl@...ts.openwall.com Subject: Re: [PATCH 00/10] add sparc64 port Hi Szabolcs, On Tue, Nov 3, 2026, at 12:44, Szabolcs Nagy wrote: <snip> >> - PLT entries are code, so the dynamic linker resolves a JMP_SLOT by >> writing and flushing instructions. > > this was where the last porting effort got stuck. > designing an abi that does not write plt would be preferable. gcc for sparc ignores -fno-plt, and neither GNU ld nor lld has a sparc64 PLT that loads its target from the GOT. Both emit code entries the dynamic linker patches (GNU ld's entries past 32768 load a pointer, but from a slot inside .plt), so .plt stays writable and executable even with -z now -z relro. With the current toolchains there is no way to avoid the write. <snip> >> - long double is IEEE quad, computed by software _Qp_* helpers in >> src/math/sparc64. Their u128 code is copied from sqrtl.c and could >> move to a shared header. > > soft fp code already exists in libgcc (with different call abi) > so ideally that logic would be used instead of replicating and > maintaining it in musl. (or using 64bit long double) > > it is a bit smaller than i expected, but still a lot to go through. On sparc libgcc has none of it: gcc emits calls to _Qp_* (_Q_* on 32-bit) for long double, and libgcc defines neither those nor __addtf3 and friends, expecting libc to provide them. Using libgcc's code would need a gcc change first, and so would a 64-bit long double: gcc rejects -mlong-double-64 with -m64. > i don't think libc-test has good coverage of fp128 > (and math code in general will not test some edge cases) > did you test the soft float code independently? Yes. Each helper ran outside libc-test on TestFloat-generated operands plus edge values, in all four rounding modes, about 9 million cases per ABI under qemu-user. Results and exception flags matched x86_64 __float128, apart from NaN sign and payload and x86 detecting tininess after rounding. With traps enabled the SIGFPE si_code was checked as well. Thanks, Imre
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.