Re: gdb / thread_db / multiple ABI question

[Steve Ellcey <sellcey@cavium.com>]

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