Re: ptrace(2) interface for TLSBASE
On 04.12.2019 19:11, Jason Thorpe wrote:
>
>
>> On Dec 4, 2019, at 8:47 AM, Kamil Rytarowski wrote:
>>
>> Today it's missing.. do we need it in core files?
>
> Seems like you would absolutely need it in core files, otherwise the debugger
> won't know what it is when performing a post-mortem.
>
> If we add a ptrace accessor a'la Linux, then it fits nicely into the existing
> model we have for ELF core files:
>
> * We also use ptrace(2) request numbers (the ones that exist in
> * machine-dependent space) to identify register info notes. The
> * info in such notes is in the same format that ptrace(2) would
> * export that information.
>
> -- thorpej
>
OK, I will add a core(5) file addition with TLS base
("PT_GET_THREAD_AREA@nnn").
While I will also include a thread name: PT_[SG]ET_THREAD_NAME.
We currently use sysctl to retrieve it from a living process, but miss
in core files. Today using sysctl is more complex than it needs to be
[1] and there is no direct translation to core(5) files.
[1]
https://github.com/llvm/llvm-project/blob/master/lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp#L158
signature.asc
Description: OpenPGP digital signature
Re: ptrace(2) interface for TLSBASE
> On Dec 4, 2019, at 8:47 AM, Kamil Rytarowski wrote: > > Today it's missing.. do we need it in core files? Seems like you would absolutely need it in core files, otherwise the debugger won't know what it is when performing a post-mortem. If we add a ptrace accessor a'la Linux, then it fits nicely into the existing model we have for ELF core files: * We also use ptrace(2) request numbers (the ones that exist in * machine-dependent space) to identify register info notes. The * info in such notes is in the same format that ptrace(2) would * export that information. -- thorpej
Re: ptrace(2) interface for TLSBASE
On Wed, 4 Dec 2019 at 11:47, Kamil Rytarowski wrote:
>
> Today it's missing.. do we need it in core files?
Here I'm guessing that LTSBASE is the thread-local-storage base
(virtual) register? If that isn't included in a core file then a
debugger is going to find it, er, difficult to locate and display a
threads local-storage variables.
Even if my guess is wrong, if there's a reason for adding it to
ptrace() then most likely that same reason applies to core files. Any
information a debugging tool can extract at runtime using either
ptrace() or /proc/PID (preferably both :-) should really be made
available in the core file. Hence, modified memory, all registers and
the executable path (but often truncated, oops). When the information
is missing, for instance /maps and /auxv, the debugger's left
scrambling trying to reconstruct those structures from memory (and
when the bug corrupts those structures, well ... :-)
But I digress.
> On 04.12.2019 16:56, Andrew Cagney wrote:
> > Where is it in a core file?
> >
> > On Tue, 3 Dec 2019 at 11:18, Kamil Rytarowski wrote:
> >>
> >> TLSBASE is stored on a selection of ports in a dedicated mcontext entry,
> >> out of gpregs.
> >>
> >> In the amd64 case mcontext looks like this:
> >>
> >> typedef struct {
> >> __gregset_t __gregs;
> >> __greg_t_mc_tlsbase;
> >> __fpregset_t__fpregs;
> >> } mcontext_t;
> >>
> >> The same situation is for: i386, arm, m68k and mips.
> >>
> >> This patch implements the accessors for amd64:
> >>
> >> http://netbsd.org/~kamil/patch-00199-TLSBASE.txt
> >>
> >> Does it look correct? If so I will add the same code for i386,
> >> i386-on-amd64, arm, m68k and mips.
> >>
> >> I'm not completely sure as l_private might be desynced with TLSBASE that
> >> was updated without letting the kernel know.
> >>
> >> I intend to get this change merged into -9, before 9.0.
> >>
> >> This interface pending to be introduced in GDB/NetBSD.
> >>
> >> NB. FS/GS in x86 __gpregs is confusing as it is not TLS base.
> >>
>
>
Re: ptrace(2) interface for TLSBASE
Today it's missing.. do we need it in core files?
On 04.12.2019 16:56, Andrew Cagney wrote:
> Where is it in a core file?
>
> On Tue, 3 Dec 2019 at 11:18, Kamil Rytarowski wrote:
>>
>> TLSBASE is stored on a selection of ports in a dedicated mcontext entry,
>> out of gpregs.
>>
>> In the amd64 case mcontext looks like this:
>>
>> typedef struct {
>> __gregset_t __gregs;
>> __greg_t_mc_tlsbase;
>> __fpregset_t__fpregs;
>> } mcontext_t;
>>
>> The same situation is for: i386, arm, m68k and mips.
>>
>> This patch implements the accessors for amd64:
>>
>> http://netbsd.org/~kamil/patch-00199-TLSBASE.txt
>>
>> Does it look correct? If so I will add the same code for i386,
>> i386-on-amd64, arm, m68k and mips.
>>
>> I'm not completely sure as l_private might be desynced with TLSBASE that
>> was updated without letting the kernel know.
>>
>> I intend to get this change merged into -9, before 9.0.
>>
>> This interface pending to be introduced in GDB/NetBSD.
>>
>> NB. FS/GS in x86 __gpregs is confusing as it is not TLS base.
>>
signature.asc
Description: OpenPGP digital signature
Re: ptrace(2) interface for TLSBASE
Where is it in a core file?
On Tue, 3 Dec 2019 at 11:18, Kamil Rytarowski wrote:
>
> TLSBASE is stored on a selection of ports in a dedicated mcontext entry,
> out of gpregs.
>
> In the amd64 case mcontext looks like this:
>
> typedef struct {
> __gregset_t __gregs;
> __greg_t_mc_tlsbase;
> __fpregset_t__fpregs;
> } mcontext_t;
>
> The same situation is for: i386, arm, m68k and mips.
>
> This patch implements the accessors for amd64:
>
> http://netbsd.org/~kamil/patch-00199-TLSBASE.txt
>
> Does it look correct? If so I will add the same code for i386,
> i386-on-amd64, arm, m68k and mips.
>
> I'm not completely sure as l_private might be desynced with TLSBASE that
> was updated without letting the kernel know.
>
> I intend to get this change merged into -9, before 9.0.
>
> This interface pending to be introduced in GDB/NetBSD.
>
> NB. FS/GS in x86 __gpregs is confusing as it is not TLS base.
>
Re: ptrace(2) interface for TLSBASE
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 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. signature.asc Description: OpenPGP digital signature
Re: ptrace(2) interface for TLSBASE
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 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 signature.asc Description: OpenPGP digital signature
Re: ptrace(2) interface for TLSBASE
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
ptrace(2) interface for TLSBASE
TLSBASE is stored on a selection of ports in a dedicated mcontext entry,
out of gpregs.
In the amd64 case mcontext looks like this:
typedef struct {
__gregset_t __gregs;
__greg_t_mc_tlsbase;
__fpregset_t__fpregs;
} mcontext_t;
The same situation is for: i386, arm, m68k and mips.
This patch implements the accessors for amd64:
http://netbsd.org/~kamil/patch-00199-TLSBASE.txt
Does it look correct? If so I will add the same code for i386,
i386-on-amd64, arm, m68k and mips.
I'm not completely sure as l_private might be desynced with TLSBASE that
was updated without letting the kernel know.
I intend to get this change merged into -9, before 9.0.
This interface pending to be introduced in GDB/NetBSD.
NB. FS/GS in x86 __gpregs is confusing as it is not TLS base.
signature.asc
Description: OpenPGP digital signature
