[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260619030107.GR27423@brightrain.aerifal.cx>
Date: Thu, 18 Jun 2026 23:01:08 -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 03:20:09AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2026-06-18 20:15:25 -0400]:
> > On Fri, Jun 19, 2026 at 01:40:49AM +0200, Szabolcs Nagy wrote:
> > > * Rich Felker <dalias@...c.org> [2026-06-18 17:58:29 -0400]:
> > > > On Thu, Jun 18, 2026 at 09:12:56PM +0200, Szabolcs Nagy wrote:
> > > > > or1k uses an unusual variant of the TLS_ABOVE_TP layout:
> > > > >
> > > > > powerpc, mips, m68k:
> > > > > pthread | tls
> > > > > +----------+-----------------+--
> > > > > | |< tpoff >|
> > > > > self a = e = m tp
> > > > >
> > > > > arm, aarch64, sh:
> > > > > pthread < gap >| tls
> > > > > +----------+-------------+------
> > > > > | | |
> > > > > self a = e = tp m
> > > > >
> > > > > or1k:
> > > > > pthread < gap >| tls
> > > > > +----------+-------------+------
> > > > > | |< tpoff >|
> > > > > self a = e m = tp
> > > >
> > > > To be sure we understand this correctly, can you draw a diagram like
> > > > this for the wrong way we have the or1k layout now?
> > >
> > > i can resend the patch, but it's just:
> >
> > No need, I just wanted to see it to make sure I understand what you
> > meant.
> >
> > > or1k old:
> > > pthread | tls
> > > +----------+--------------------
> > > | |
> > > self a = e = m = tp
> > >
> > > or1k fixed:
> > > pthread < gap >| tls
> > > +----------+-------------+------
> > > | |< tpoff >|
> > > self a = e m = tp
> >
> > OK, so it's essentially the tp being aligned to something nonzero mod
> > tls_align. That would be an alternate way to implement it (adding
> > support the the arch to declare the desired residue), though as long
> > as we can just do it with a GAP_ABOVE_TP, that seems ok.
> >
> > But are you sure this is correct setting TPOFF_K to cancel the
> > GAP_ABOVE_TP? TPOFF_K affects all modules not just the main program. I
> > don't see how changing it doesn't break initial-exec accesses to TLS
> > in libraries.
>
> i wrote some tests now, it all looks good.
>
> with diagram:
>
> pthread < gap >| tls |tlsvar
> +----------+-------------+-------+--+-----
> | |< tpoff >| |
> self a = e m = tp modtls
>
> ie access:
> tlsvar_addr = tp + *reloc
>
> ldso:
> *reloc = tlsvar_offset + modtls_offset + TPOFF_K
> where
> tlsvar_offset = tlsvar - modtls
> modtls_offset = modtls - a
> TPOFF_K = -tpoff = a - tp
> so
> tlsvar_addr = tp + (tlsvar - tp)
I think I missed that TP_OFFSET is also set to cancel it.
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.
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.)
- 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.
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.
