From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paire To: Mark Kettenis Cc: "H . J . Lu" , GDB Subject: Re: Is the current gdb 5.1 broken for Linuxthreads? Date: Wed, 19 Sep 2001 07:39:00 -0000 Message-id: <200109191438.f8JEcoR29295@mailhost.ri.silicomp.fr> References: X-SW-Source: 2001-09/msg00160.html Mark Kettenis writes: > "H . J . Lu" 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