[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 May 2018 08:33:17 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: TLS issue on aarch64
* Rich Felker <dalias@...c.org> [2018-05-28 18:15:21 -0400]:
> On Mon, May 28, 2018 at 10:47:31PM +0200, Szabolcs Nagy wrote:
> > another issue with the patch is that if tp is aligned then pthread_t
> > may not get aligned:
> >
> > tp == self + sizeof(pthread_t) - reserved
>
> This expression does not look correct; it would have tp point
> somewhere inside of the pthread structure rather than just past the
> end of it.
>
this is the current tp setup on
aarch64, arm and sh4, see TP_ADJ
we can just make tp = self+sizeof(pthread_t)
but then there will be a small unused hole
> Maybe your code is doing this to avoid wasted padding, but if so I
> think that's a bad idea. It violates the invariant that the pthread
> structure is at a constant offset from tp, which is needed for
> efficient pthread_self and for access to fixed slots at the end of it
> (like canary or dtv copy).
>
> > so sizeof(pthread_t) - reserved must be divisible with
> > gcd(alignment of tp, alignof(pthread_t)) to be able to make both
> > self and tp aligned.
> >
> > this is not an issue on current targets with current pthread_t,
> > but we may want to decouple internal struct pthread alignment
> > details and the abi reserved tls size, i.e. tp_adj could be like
> >
> > tp == alignup(self + sizeof(pthread_t) - reserved, alignof(pthread_t))
> >
> > or we add a static assert that reserved and alignof(pthread_t)
> > are not conflicting.
>
> Maybe I'm misunderstanding what "reserved" is, since you're talking
> about a static assert...?
>
it is the abi reserved space after tp
(the bfd linker calls it TCB_SIZE)
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.
