Re: TLSDESC clobber ABI stability/futureproofness?

[Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>]

On 11/10/18 04:53, Alexandre Oliva wrote:
> On Oct 10, 2018, Rich Felker <dalias@libc.org> wrote:
>> 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.
> 
> That's unfortunate.  I'm not sure I understand the reasoning behind this
> intent.  Maybe we should discuss it further?
> 

sve registers overlap with existing float registers
so float register access clobbers them.

so new code is suddenly not compatible with existing
tlsdesc entry points in the libc.

i think extensions should not cause such abi break.
we could mark binaries so they fail to load on an old
system instead of failing randomly at runtime, but
requiring new libc for a new system is suboptimal
(you cannot deploy stable linux distros then).

if we update the libc then the tlsdesc entry has to
save/restore all sve regs, which can be huge state
(cause excessive stack usage), but more importantly
suddenly the process becomes "sve enabled" even if it
otherwise does not use sve at all (linux kernel keeps
track of which processes use sve instructions, ones
that don't can enter the kernel more quickly as the
sve state does not have to be saved)

i don't see a good solution for this, but in practice
it's unlikely that user code would need tls access and
sve together much, so it seems reasonable to just add
sve registers to tlsdesc call clobber list and do the
same for future extensions too (tlsdesc call will not
be worse than a normal indirect call).

(in principle it's possible that tlsdesc entry avoids
using any float regs, but in practice that requires
hackery in the libc: marking every affected translation
units with -mgeneral-regs-only or similar)