expected behavior of GNU/Linux gcore and corefiles

[Andrew Cagney <ac131313 at redhat dot 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