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

[Andrew Cagney <cagney@gnu.org>]

> Joel Brobecker <brobecker@gnat.com> writes:
> 
> 
>>> According to corelow.c:add_to_thread_list(), the thread PTID
>>> is a degenerated {pid, 0, 0} where pid is just the number in the section
>>> name where the thread has been dumped (ie section ".reg/1234" => thread
>>> ptid = {1234, 0, 0}).
> 
> 
> 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.

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

Andrew