On 04.12.2019 04:10, Kamil Rytarowski wrote: > 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 > Hm... I was too quick. I noted that there is already an interface in a newer Linux kernel: PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA. (However it was implemented only for few CPUs and not uniformly as typically in the Linux ptrace()). It has the same purpose as a generic API to access l_private and there is a user in GDB for it with IPA [2]. [2] https://suchakra.wordpress.com/2016/06/29/fast-tracing-with-gdb/ PTRACE_GET_THREAD_AREA is used in few other smaller projects (edb, custom debuggers). PTRACE_SET_THREAD_AREA is used in usermode Linux. Both interfaces (get and set) find uses. I will go for an API: PT_SET_THREAD_AREA and PT_GET_THREAD_AREA and try to target all CPUs.
Attachment:
signature.asc
Description: OpenPGP digital signature