On Wed, 4 Dec 2019 at 11:47, Kamil Rytarowski <n...@gmx.com> 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 <n...@gmx.com> 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.
> >>
>
>
