[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <09dfef26-96b0-4a05-95b4-47073cf9d2aa@app.fastmail.com>
Date: Wed, 04 Nov 2026 09:58:38 +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 22:39, Szabolcs Nagy wrote:
>> 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.
Both ld.so implementations map the RELRO range PROT_READ after
relocation, and on sparc .plt is code, so it cannot go under RELRO
without losing exec. The linkers place it after the RELRO end, in the
same RWX segment as .got, .data and .bss.
> 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.
It is also the practical one. gcc and clang both ignore -fno-plt on
sparc, and musl builds with either, so this means patches to two
compilers for one libc, with no telling how long they would take to
be accepted, if at all. Until then the port could not be built with
any released compiler. I'd rather keep the PLT write. It is confined
to the ARCH_PLT_WRITE hook and its sparc definitions, so it can go if
the compilers ever support -fno-plt.
Separately, I found that _start does not realign the stack when ld.so
is run as a command, which breaks long double printing on sparc64 and
faults on sparc. v2 will fix that in both ports.
Best,
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.
