From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Cownie To: Eric Paire Cc: "H . J . Lu" , Andrew Cagney , Mark Kettenis , GDB Subject: Re: Is the current gdb 5.1 broken for Linuxthreads? Date: Fri, 21 Sep 2001 05:25:00 -0000 Message-id: <15kPM8-1OK-00@etnus.com> References: <200109211153.f8LBrww08032@mailhost.ri.silicomp.fr> X-SW-Source: 2001-09/msg00189.html > == Eric > > == Me, > > That seems a somewhat perverse approach, given that > > > > 1) the ELF core dump format easily handles a genuine multi-threaded > > core dump (cf Solaris, IRIX, ...) > > > This is not feasible in Linux as Linus does not want to implement any > specific pthread feature in the kernel (and the core dump is 100% > kernel code), e.g. why a thread doing a fault should kill the other, > perhaps the application is written in such a way that it can recover > from it. It remains perverse no matter what Linus' view of it is. (I'm sure he would be happy to own to being perverse under some circumstances !). The argument you outline (that there are threaded codes for which dumping the whole process as a result of a failure in one thread would be the wrong behaviour) does not imply that there are no codes for which dumping the whole process on thread failure would be the _correct_ behaviour. All it argues is that the behaviour on thread error needs to be configurable on a per-proces basis; that is not a big surprise. Whether you view such a per-process piece of state and behaviour as being "pthread specific" is a political (not a technical) choice. Were such an implementation to exist it would be useful to pthread code, but would also be equally useful to codes which create threads with naked clone but want to dump all threads on error. After all, the kernel implements clone, and pthreads uses that but no-one seems to think clone should go away because it's "pthread support in the kernel". > If you look carefully at it, it only dumps the first thread, and the > dump is no longer allowed for any thread of this process. In which case it is still _not_ a multi-threaded core dump, which is what you started off by asking for. It's just a normal core dump of one thread. (And information about all other threads is lost). While this may be more useful than the previous state (dump a core file from a thread which you almost certainly weren't interested in), no matter how you look at it it's not a multi-threaded core dump. > > 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 But you just said that there still are _no_ MT core dumps for the debugger to understand. What's new to understand about a normal single threaded core dump from one thread ? > > What is wanted is a genuine multi-threaded core dump, not this > > horror... > > > I would not say that it is, because it exists, Where ? You just told me it didn't and that all that gets dumped is one single-threaded core file. > and we have been living without anything for years. This is just another spin on "Eat sh*t, 10 billion flies can't be wrong", an argument I have never found very convincing. -- Jim James Cownie Etnus, LLC. +44 117 9071438 http://www.etnus.com