This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb / thread_db / multiple ABI question
I never noticed that the 3 TIDs were all the same. I am looking
at elf.c:elfcore_grok_note and I noticed something odd that doesn't
seem related to the ILP32 work. If I look at the note->type
values that come in and get used in the switch statement, I see 0x401,
0x402, 0x403, and 0x404. But 0x404 is not defined
in include/elf/common.h. There is a 0x405, but no 0x404. Any
idea why?
Steve Ellcey
sellcey@cavium.com
On Mon, 2017-07-10 at 19:21 +0100, Pedro Alves wrote:
> 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