[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261103213921.GW3542221@port70.net>
Date: Tue, 3 Nov 2026 22:39:21 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: Imre Kaloz <kaloz@...nel.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH 00/10] add sparc64 port
* Imre Kaloz <kaloz@...nel.org> [2026-11-03 13:56:48 +0100]:
> 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.
i don't understand why plt stays writable with -z now
but in general a musl port may need toolchain changes,
we can do things differently.
gcc -fno-plt sounds like a reasonable approach, musl
can even be -fpic only (that seems less problematic
than writable plt. upstreaming to gcc is more work
but from musl pov the result is better).
i guess it depends on the goal, if it is to get the port
working with minimal changes then writable plt is the
easiest.
> >> - 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.
this is unfortunate.
> > 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.
sounds good.
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.
