This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb / thread_db / multiple ABI question
On 07/10/2017 07:02 PM, Steve Ellcey wrote:
> No, without thread_db I get this:
>
> (gdb) file m32
> Reading symbols from m32...done.
> (gdb) core c_32
> [New LWP 79425]
> [New LWP 79425]
> [New LWP 79425]
This means that GDB/bfd thinks that there are 3 threads
in the core, but they all have the same TID, which is of course
bogus. So this still looks to me like something is wrong on
the bfd side. Try "objdump -h c_32". You should see
one ".reg/NNN" section per thread, like e.g.:
$ objdump -h core.1904 | grep "reg/"
1 .reg/1904 000000d8 0000000000000000 0000000000000000 000006a0 2**2
9 .reg/1909 000000d8 0000000000000000 0000000000000000 00000e00 2**2
13 .reg/1910 000000d8 0000000000000000 0000000000000000 00001560 2**2
Put a breakpoint on elf.c:elfcore_grok_note, and step through it,
checking that the proper NT_PRSTATUS / NT_PSINFO hooks get called
via the elf_backend_data vector, and check that they're extracting
the right fields/offsets out of the core structures.
Once you get 3 threads without libthread_db., then this:
> (gdb) info threads
Found 0 new threads in iteration 0.
> Id Target Id Frame
> * 3 Thread 0xf739ef70 (LWP 8660) 0x00400680 in doSomeThing ()
> 4 Thread 0xf69bf490 (LWP 8662) warning: Couldn't find general-purpose registers in core file.
> PC register is not available
should not longer happen. The above with libthread_db is very likely
happening because libthread_db found a thread that maps to LWP 8662
in libpthread's internal data structures, but then GDB/bfd can't
find the ".reg/8662" note/section in the core dump.
Thanks,
Pedro Alves