This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: expected behavior of GNU/Linux gcore and corefiles
On Sat, Mar 01, 2003 at 10:16:39PM -0500, Andrew Cagney wrote:
(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
Hmm, what platform is that? I've never seen a GNU/Linux
implementation, but I'm a youngun.
FreeBSD, solaris. This is the `expected behavior'.
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?
Some platforms yes, some platforms no. I've had Linux patches to do
this for some time. I believe kernels as of 2.5.50 or so do it also.
Sounds like bugs. If GDB is to give the user the best ptrace experience
then GDB will need that information.
- For GDB to completly implement the above, is it forced to use
libthread-db?
Not necessarily.
Here's the added value we get from libthread_db right now, on "normal"
GNU/Linux threading (either LinuxThreads or NPTL, but not including the
M-N stuff that NGPT does):
- Thread IDs, instead of just LWP IDs. Big deal.
My point is that this _is_ a big deal.
GDB, in conjunction with libthread-db, should provide this interface.
In fact, GDB+libthread-db should be providing a lot more:
`info mutex'
`info lwp'
It's the same situtation as for source code debugging. While the user
normally only views source code and variables (i.e., threads), GDB does
also allow the user to open the bonnet and poke around in the registers
and assembly (i.e., the lwp layer).
- Thread local storage offsets.
We could do find TLS areas with a per-architecture hook; libthread_db
finds the TLS area by grubbing through the thread descriptor, but given
that we have each LWP's state we could just do it in the
platform-mandated way (i.e. examining the registers in question, etc.)
I don't know offhand if the necessary information for Alpha, i386, etc.
TLS is in core files - i.e. platforms where it's more than just a
register.
Per above, sounds like a bug.
[...]
Thread_db is a great interface for querying threads. It's not so good
for debugging them; for a case in point see my messages about the FAIL
at the end of print-threads.exp. Thread_db does not interact well with
debugging the thread manager itself, which is a very important feature
for me.
And that was a bug. I'm told that the new libthread-db code dropped the
manager thread and, in the process, eliminated the problem.
Andrew