mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: TLSDESC register-preserving mess
Date: Wed, 10 Oct 2018 09:52:41 -0400	[thread overview]
Message-ID: <20181010135241.GN17110@brightrain.aerifal.cx> (raw)
In-Reply-To: <20181010131926.GT10209@port70.net>

On Wed, Oct 10, 2018 at 03:19:26PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2018-10-09 21:26:20 -0400]:
> > As written, the aarch64 and arm asm save and restore float/vector
> > registers around the call, but I don't think they're future-proof
> > against ISA extensions that add more such registers; if libc were
> 
> at least on aarch64 for now the approach is to add new vector
> registers to the tlsdesc clobber list in gcc (and document
> this in the sysv abi, except that's not published yet).
> 
> the reasoning is that it makes it safe to use tlsdesc with
> old dynamic linker (new vector registers overlap with old
> ones so old dynamic linker can clobber them) without much
> practical cost: it's unlikely that vector code needs to
> access tls (in vectorized loops the address is hopefully
> computed outside the loop and vector math code should not
> use tls state in the fast path if it wants to be efficient)

Any idea if other archs are willing to commit to the same?

Even if they are, the second idea of getting rid of __tls_get_new
entirely is still somewhat appealing, in that it makes all dynamic TLS
access faster and reduces the amount of asm needed. But a committment
not to add new call-saved registers to the TLSDESC ABIs would solve
the immediate problem (albeit with some hwcap fiddling for 32-bit x86
where mmx, sse, etc. perhaps need to be saved conditionally).

Rich


      reply	other threads:[~2018-10-10 13:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10  1:26 Rich Felker
2018-10-10  2:35 ` Rich Felker
2018-10-10 13:19 ` Szabolcs Nagy
2018-10-10 13:52   ` Rich Felker [this message]

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=20181010135241.GN17110@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --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).