Re: Is the current gdb 5.1 broken for Linuxthreads?

[Eric Paire <paire at ri dot silicomp dot fr>]

Mark Kettenis <kettenis@science.uva.nl> writes:

> "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.
> 
As original developer of the linuxthread patches for GDB-4.17, I mostly
agree with Mark. At that time, I saw a lot of complaints that GDB was
unable to debug LinuxThreaded programs (and the only answer was do it
yourself, which I did). The only benefit I saw with this version is that
the support existed and a lot of people used it (which probably was the
main reason why GDB developers decided to support it in a cleaner way
in GDB-5.0).

I must add that I have been using gdb-4.18 even on RedHat-7.1, as official
GDB-5.0 and development version of GDB-5.1 have been buggy. But now,
it seems to me as useable as the gdb-4.18 one, so I switched to the
current GDB-5.1. GDB_4.18 is now dead, and we must help GDB-5.1 to
become the version that people have to use for linuxthreaded apps.

> 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.
> 
I don't agree with you: There are at least 2 bugs in the current Linux
kernel which makes you think that the support is fragile:
1) SIGSTOP management is not-POSIX conformant
2) reparenting of debugged processes is buggy

I already started a thread to explain that that stopping all threads in
a synchronous way was an illusion: Think of a 2-way processor on which
2 threads are running on each processor: If one thread stops, the time
required by one processor to handle the trap, discover that others
threads must be stopped, makwe the interprocessor request, ... allows
the other thread to run thousands of instructions on the second
processor before being stopped. The result is that you think all threads
have stopped at the same time, while it's false, even if you have the best
interface you can think of.

> > 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.
> 
I must say that I have been very disappointed with GDB-5.0 (which was
almost unusable with "real" multithreaded applications). But, the fact
that I switched from my version of GDB-4.18 towards GDB-5.1 seems to
me a good sign, even if I agree that there is still some minor enhancements
to make.

Just my 2 cents,
-Eric
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Web  : http://www.ri.silicomp.com/~paire  | Groupe SILICOMP - Research Institute
Email: eric.paire@ri.silicomp.com         | 2, avenue de Vignate
Phone: +33 (0) 476 63 48 71               | F-38610 Gieres
Fax  : +33 (0) 476 51 05 32               | FRANCE