TLSDESC clobber ABI stability/futureproofness?

[Rich Felker <dalias at libc dot org>]

It's recently come up in musl libc development that the tlsdesc asm
functions, at least for some archs, are potentially not future-proof,
in that, for a given fixed version of the asm in the dynamic linker,
it seems possible for a future ISA level and compiler supporting that
ISA level to produce code, in the C functions called in the dynamic
fallback case, instructions which clobber registers which are normally
call-clobbered, but which are non-clobbered in the tlsdesc ABI. This
does not risk breakage when an existing valid build of libc/ldso is
used on new hardware and new appliations that provide new registers,
but it does risk breakage if an existing source version of libc/ldso
is built with a compiler supporting new extensions, which is difficult
to preclude and not something we want to try to preclude.

For aarch64 at least, according to discussions I had with Szabolcs
Nagy, there is an intent that any new extensions to the aarch64
register file be treated as clobbered by tlsdesc functions, rather
than preserved. However I can't find any statement of such intent for
x86 or in general.

In the x86 spec, the closest I can find are the phrasing:

    "being able to assume no registers are clobbered by the call"

and the comment in the pseudo-C:

    /* Preserve any call-clobbered registers not preserved because of
       the above across the call below.  */

Source: https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt

What is the policy for i386 and x86_64? Are normally call-clobbered
registers from new register file extensions intended to be preserved
by the tlsdesc functions, or clobberable by them? Is fxsave/xsave
supposed to be used when available? What about more obscure stuff like
3dnow or other vendor extensions?

Is there any intended policy for other/future archs that add TLSDESC
support?

I'm hopeful there's some hidden intent I'm just not finding that makes
this issue a lot simpler than I fear it is. If not we're considering
raising a signal to request installation of new dynamic TLS (punting
to the kernel to save/restore everything) or getting rid of
just-in-time installation of new TLS entirely in favor of havign
dlopen install it:

https://www.openwall.com/lists/musl/2018/10/10/2
https://www.openwall.com/lists/musl/2018/10/10/3

Rich