|
|
Message-ID: <20260619001525.GQ27423@brightrain.aerifal.cx> Date: Thu, 18 Jun 2026 20:15:25 -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: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. 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.