On 03.12.2019 17:55, Joerg Sonnenberger wrote: > On Tue, Dec 03, 2019 at 05:11:49PM +0100, Kamil Rytarowski wrote: >> TLSBASE is stored on a selection of ports in a dedicated mcontext entry, >> out of gpregs. > > That's an implementation detail and IMO something we shouldn't leak > outside the arch. Just provide an accessor for l_private. There are then > two possible options: > (1) An MD register is used directly for the TLS base. In that case, the > register should be used and l_private is normally irrelevant. > (2) No MD register is used (directly). In that case l_private is > correct. > > Joerg > As long as I sympathize with the idea of making it uniform and hide the internals I think this is not the best approach here. We exactly want to reconstruct more or less mcontext (known as user-data) on per-CPU basis. This means that we want to leak the idea of an OS of the registers/state on certain CPU into an application through the ptrace(2) accessors. The accessor is planned to be used in CPU-specific code in debuggers. We already preserved an LLDB field for TLS in amd64 and i386 (on your suggestion), reflecting the format of x86 mcontext. I don't have users pending where such uniform API would be used. Today the only short term planned user is GDB (next, sooner or later LLDB will gain it). There are no other recognized open-source projects that I am aware that make use of it (except dosemu for DPMI/VM86 and recognition of strace&rr for tracking syscalls) I think it can be interesting to provide PT_[SG]ET_TLS() that manages TLS register inside mcontext/gpregs, but I don't see/have any users for it today, so I want to avoid it, at least until the day it can have 1 real user. A question is what to do with vax. As far as I can see, reading/writing l_private is still valid for it. On the other hand there are ideas to spare a register for TLS and break ABI with other changes, this is why I prefer to wait with it. Our advantage of picking the PT_[GS]ETTLSBASE API over what we get inside FreeBSD/Linux is that it is uniformly named regardless of arch/compat. Linux and FreeBSD must detect arch and compat mode before prompting either FS or GS (on x86) [1]. [1] https://sources.debian.org/src/gdb/8.3.1-1/gdb/gdbserver/linux-x86-low.c/#L197
Attachment:
signature.asc
Description: OpenPGP digital signature