This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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.
(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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |