Re: Is the current gdb 5.1 broken for Linuxthreads?

[James Cownie <jcownie@etnus.com>]

> == 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	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com