[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260619115036.GT3520958@port70.net>
Date: Fri, 19 Jun 2026 13:50:36 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] or1k: fix local-exec tls with large alignment
* 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)
>
> - 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.
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.
