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