[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260619160852.GS27423@brightrain.aerifal.cx>
Date: Fri, 19 Jun 2026 12:08:52 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] or1k: fix local-exec tls with large alignment
On Fri, Jun 19, 2026 at 01:50:36PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2026-06-18 23:01:08 -0400]:
> > Now that I look at it, I'm confused why we have TPOFF_K. Isn't it
> > always the negation of TP_OFFSET? It looks like it's a remnant of
> > stuff prior to commit ea71a9004e08030a15d45186e263fd2b0c51cc25 where
> > there was no unified TP_OFFSET, only explicit per-arch code.
> >
> > If this is correct, I think we could remove TPOFF_K and replace it
> > with -TP_OFFSET in dynlink.c. But this would be a separate change to
> > do after fixing the bug.
>
> i was wondering about that.
>
> >
> > Adding a few notes from re-figuring this stuff out while checking,
> > which we should check for correctness and document at some point:
> >
> > - DTP_OFFSET is ABI due to local-dynamic model having offsets set by
> > linker.
> >
> > - TP_OFFSET-GAP_ABOVE_TP is ABI due to local-exec model having offsets
> > set by linker. (Your fix is using that only the difference is ABI;
> > the individual TP_OFFSET isn't ABI by itself.)
>
> tp%tls_align is abi, which is TP_OFFSET (with large enough tls_align)
>
> because we need alignup(tp-off, tls_align), off is not enough.
> (in my model tpoff,gap are relative to an alignment point
> there may be better ways to express this with % arithmetics).
>
> (since this is only for the main exe tls, other modules could
> in principle reuse the gap or alignment holes or even left overs
> below pthread_self, likely with significant effort and marginal
> benefit in practice)
Yeah. I think the only way I'd want to consider altering the layout is
if we thought it could bring significant hardening benefits. But
having arrays in TLS is unusual usage and I don't think buffer
overflows in TLS are a common risk.
> > - GAP_ABOVE_TP is ABI only affecting main executable with TLS aligned
> > beyond the alignment of GAP_ABOVE_TP.
> >
> > Also, GAP_ABOVE_TP is a misnomer as it stands, since in the or1k case
> > the gap is below the tp. It should probably be called LE_TLS_GAP or
> > something.
>
> btw TLS_ABOVE_TP name is also incorrect (although it is better
> than 'variant 1' or the glibc TLS_TCB_AT_TP vs TLS_DTV_AT_TP)
>
> i guess all the variants are mainly about local-exec, without
> that the tls layout could be arranged to be the same across
> targets, it's difficult to come up with a good name.
The real ABI distinguishing property is whether it's the top of bottom
of the local-exec TLS that's pinned to a fixed offset from the TP.
AFAICT everything else we do conditional on "TLS_ABOVE_TP" is an
implementation detail.
Rich
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.
