Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.