Re: thread ptids when debugging from core file (x86-linux)

[Joel Brobecker <brobecker at gnat dot com>]

> >I've always assumed that corelow.c's mapping between .reg sections and
> >threads was intended as a minimal fallback. The module I wrote for
> >NetBSD's threads (which I'll get into shape for the FSF tree Real Soon
> >Now) punts that list and generates its own list of threads from the
> >memory structures of libpthread in the core file, just as it would for
> >a live process.
> 
> Yes.

So do you think I'll have to dig into the inferior memory for data used
by the libpthread library to find that information? Is this something
that would be portable across NPTL versions? Supposing we want to go
that route, does anybody know where to find some documentation (or some
code) that exposes the data structures, so I can try digging into them?

> Joel, this observation of yours is the key:
> 
> >Unfortunately, that doesn't work when debugging from a core file,
> >because the PTID of the threads are not the same as when debugging
> >live. 
> 
> The best way to appreciate this is to consider:
> 
> (gdb) attach program
> (gdb) info threads
> thread output #1
> (gdb) info lwp -- yes ok, that cmd doesn't exist :-)
> lwp output #1 (different to the thread output)
> (gdb) gcore program.gcore
> (gdb) detach
> Segmentation fault core dumped to program.core
> (gdb) corefile program.core
> (gdb) info threads
> identical thread output #2
> (gdb) info lwp
> identical lwp output #2
> (gdb) corefile program.gcore
> (gdb) info threads
> also identical output #3
> (gdb) info lwp
> also identical lwp output #3

I am sorry, I don't understand what you are saying. What do you
mean by "identical output #n"? What is it identical to? to output
#1? (right now, it is not).

Thanks,
-- 
Joel