Re: Is the current gdb 5.1 broken for Linuxthreads?

[Mark Kettenis <kettenis at science dot uva dot nl>]

"H . J . Lu" <hjl@lucon.org> writes:

> It seems that the Linuxthreads support in gdb 5.1 is very fragile. In
> some aspects, it is worse than gdb 4.17/4.18 with various Linuxthreads
> patches. The problem seems to be gdb starts with the none-threaded mode
> and the Linuxthreads support is only activated at very late time. In
> some cases, it is too late. One problem seems to call wait () on cloned
> processes. Can't we treat none-threaded Linux procceses as a
> Linuxthreads with one thread? That is what gdb 4.17 does.

And in some sense the threads support in GDB 5.1 is better than GDB
4.17/4.18 with patches.  The 4.17/4.18 Linuxthreads-patches are
unmaintainable.  Whenever the internals of the threads library change
you'll need to patch GDB.  They also make it very hard to add support
for other threads libraries to GDB.

Not activating the LinuxThreads support until the threads library is
detected by GDB still seems the right approach to me.  The
LinuxThreads support has to do certain things that interfere with the
process being debugged, and you don't want that for non-threaded
processes.  That said, I think it should be possible to make the LWP
layer in lin-lwp.c (which is largely threads library independent) the
default layer for Linux without any unwanted side-effects.  At least
for 2.4 kernels.

BTW, debugging threaded apps under Linux will always be somewhat
fragile as long as there isn't a sane kernel threads interface to the
kernel.  There should be an interface to stop all threads in a
synchronous way.  Unfortunately, I have no hope that such an interface
will be added to the kernel.

> BTW, people may be very disappointed at the current Linuxthreads
> support in gdb 5.1.

If they are they should help improving it.  Several people have
reported problems.  Most of these I have been unable to reproduce.
Hardly anyone even bothers to answer me if I ask for a small
self-contained testcase for the problem.

Mark