Re: gdb / thread_db / multiple ABI question

Steve Ellcey
2017-07-10T19:45:56Z

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