On 11/10/18 04:53, Alexandre Oliva wrote: > On Oct 10, 2018, Rich Felker <dal...@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)
