This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Is the current gdb 5.1 broken for Linuxthreads?
- To: Eric Paire <paire at ri dot silicomp dot fr>
- Subject: Re: Is the current gdb 5.1 broken for Linuxthreads?
- From: ac131313 at cygnus dot com (Andrew Cagney)
- Date: Fri, 21 Sep 2001 11:38:31 -0400 (EDT)
- Cc: James Cownie <jcownie at etnus dot com>, "H . J . Lu" <hjl at lucon dot org>, Andrew Cagney <ac131313 at cygnus dot com>, Mark Kettenis <kettenis at science dot uva dot nl>, GDB <gdb at sourceware dot cygnus dot com>
> > 2) debuggers already know how to read such multi-threaded core dumps
> > and present them as a process with multiple threads.
> >
> The point is that debugger should understand the way MT core dumps are
> done
Including multiple threads in a single core dump is a pretty well
understood problem. Believe it or not that problem is solved by a
standard and that standard, on the whole, is a good thing. In this
case it provides a clear, well understood interface between the
debugger and the kernel. Re-invent the standard (without very good
reason and I don't see one here) and everyone looses - we spend our
time trying to keep things in sync.
Case in point? GDB's support of Linux's kernel thread model. Until
people sat down and came up with the libthread / threaddb interface we
were in a situtation where, every time a new linux kernel was spun,
we'd need to, yet again, re-spin GDB (and in the process break
compatibility with some other kernel). While the current GDB thread
code may not be perfect it is still streets ahead of what we had
before. Why? Because it is now possible to fix a problem once and
not have it come back again and again and again.
Should GDB be able to manage multiple simultaneous core files? Yes,
after all, why not. Should such a feature be made a predicate GDB
supporting Linux's multi-threaded core dumps. I think not. I think
adding such a feature is outside of the scope of the immediate problem
- getting the linux kernel to do a core dump that complies to current
conventions.
enjoy,
Andrew
(1) The floating-point support has been overhauled. Ditto for the
register model. The target vector is probably next. If you know
anything about GDB;s internals you'll know that an overhall of the
target vector is a precursor to many new features, support for
multiple core dump files is probably one.