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.
>
