From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: TLS issue on aarch64
Date: Fri, 1 Jun 2018 11:38:11 +0200 [thread overview]
Message-ID: <20180601093811.GN4418@port70.net> (raw)
In-Reply-To: <20180601005200.GO1392@brightrain.aerifal.cx>
* Rich Felker <dalias@libc.org> [2018-05-31 20:52:00 -0400]:
> On Fri, Jun 01, 2018 at 02:11:02AM +0200, Szabolcs Nagy wrote:
> > aarch64: tp + alignup(16, align) must be aligned == tp must be aligned
>
> OK, I see two possible solutions here:
>
> 1. tp==self+sizeof(struct pthread). In this case we'll waste some
> space (vs the current approach) when no extra alignment is needed, but
> it's simple and clean because all the alignments match up naturally.
>
> 2. tp==self+sizeof(struct pthread)-16 (or rather -reserved in
> general). This preserves the current memory usage, but requires
> complex new alignment logic since self will no longer be aligned mod
> tls_align when tls_align>reserved.
>
> I pretty strongly prefer option 1.
>
ok.
> In either case, the main_tls.offset/app.tls.offset value needs to
> correctly reflect the offset of the TLS from TP, so it either needs to
> be alignup(reserved,tls_align) or alignup(reserved,tls_align)-reserved
> depending on option 1 or 2. After that change is made, we need to make
> sure the storage needs (libc.tls_size) are computed correctly and
> account for the extra space due to the initial positive offset.
>
> No change is then needed in __copy_tls.
>
> Changes to TP_ADJ and __pthread_self are needed to get reserved out of
> them, and the value of reserved needs to be provided somewhere else
> for computing main_tls.offset.
>
ok.
i'll try to prepare a patch.
> > for initial-exec to work:
> > tp + *got - add must be aligned (i.e. *got has to be set up to meet
> > the alignment requirement of the module, this does not seem to require
> > realignment of tp so even runtime loading of initial-exec tls should
> > be possible assuming there is enough space etc...)
>
> There's never space so it's not even a question, but even if there
> were, no, it can't be done because tp will not be aligned mod some
> possibly-larger alignment than the alignment in effect at the time the
> thread was created.
>
ah right because there are many threads with different tp
so tp + *got can only be aligned if tp modulo alignment
is the same in all of them.
next prev parent reply other threads:[~2018-06-01 9:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 12:40 Phillip Berndt
2018-05-25 14:50 ` Szabolcs Nagy
2018-05-25 21:38 ` Szabolcs Nagy
2018-05-25 22:20 ` Phillip Berndt
2018-05-26 0:54 ` Szabolcs Nagy
2018-05-26 8:24 ` Phillip Berndt
2018-05-27 0:34 ` Rich Felker
2018-05-28 20:47 ` Szabolcs Nagy
2018-05-28 22:15 ` Rich Felker
2018-05-29 6:33 ` Szabolcs Nagy
2018-05-31 15:22 ` Phillip Berndt
2018-06-01 0:11 ` Szabolcs Nagy
2018-06-01 0:52 ` Rich Felker
2018-06-01 9:38 ` Szabolcs Nagy [this message]
2018-05-27 0:17 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180601093811.GN4418@port70.net \
--to=nsz@port70.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).