expected behavior of GNU/Linux gcore and corefiles

Andrew Cagney
2003-03-02T03:14:32Z

(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