From mboxrd@z Thu Jan 1 00:00:00 1970 From: ac131313@cygnus.com (Andrew Cagney) To: Eric Paire Cc: James Cownie , "H . J . Lu" , Andrew Cagney , Mark Kettenis , GDB Subject: Re: Is the current gdb 5.1 broken for Linuxthreads? Date: Fri, 21 Sep 2001 08:39:00 -0000 Message-id: <20010921153831.C9A513E0B@localhost.cygnus.com> References: <200109211153.f8LBrww08032@mailhost.ri.silicomp.fr> X-SW-Source: 2001-09/msg00191.html > > 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.