expected behavior of GNU/Linux gcore and corefiles

[Andrew Cagney <ac131313@redhat.com>]

(notes from a hallway conversation, I had a recollection that, at some 
stage, the attempt to load libthread db over a core file on GNU/Linux 
was disabled.)

When using GDB on a live threaded program that puts all threads into 
tight infinite loops (while (1);), I'll do something like:

     $ ./a.out &
     Pid 1234
     $ gdb ./a.out 1234
     (gdb) info threads
     ....
     (gdb) quit

As a user I'd also expect sequences such as:

     $ kill -QUIT 1234
     $ gdb ./a.out core
     (gdb) info threads
     ....
     (gdb) quit

and:

     $ gcore 1234
     $ gdb ./a.out core
     (gdb) info threads
     ....
     (gdb) quit

and:

     $ gdb ./a.out 1234
     (gdb) gcore
     (gdb) quit
     $ gdb ./a.out core
     (gdb) info threads

to all come back with effectively the same output.  Further, on both 
live and corefile targets, I'd expect to be able to select/examine each 
thread vis:

     (gdb) thread 5
     11    i = i + 1;
     (gdb) list
     10    __thread__ i = 1;
     11    i = i + 1;
     (gdb) print i
     $1 = 1

(which would involve thread local storage).

Two problems come to mind:

- Is the kernel including all the raw information needed to do this in 
the core file?

- For GDB to completly implement the above, is it forced to use 
libthread-db?

My instincts tell me that, to completly implement the above 
functionality, GDB is always going to need libthread-db.  If GDB could 
implement the above on a core file without using libthread-db, then GDB 
could also implement the above on a live target also without using 
libthread-db.  This is because a core file is always going to contain a 
subset of the information made available via ptrace et.al.

Andrew