Re: Is the current gdb 5.1 broken for Linuxthreads?

[ac131313 at cygnus dot com (Andrew Cagney)]

> > 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.