From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26727 invoked by alias); 11 Dec 2004 18:50:03 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26663 invoked from network); 11 Dec 2004 18:49:55 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 11 Dec 2004 18:49:55 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iBBIngBR008214; Sat, 11 Dec 2004 19:49:42 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iBBInfc4007868; Sat, 11 Dec 2004 19:49:41 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iBBInZRn007863; Sat, 11 Dec 2004 19:49:35 +0100 (CET) Date: Sat, 11 Dec 2004 19:06:00 -0000 Message-Id: <200412111849.iBBInZRn007863@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: eliz@gnu.org, jjohnstn@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <20041211163652.GB13865@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 11 Dec 2004 11:36:52 -0500) Subject: Re: [RFA]: Modified Watchthreads Patch References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <01c4df0c$Blat.v2.2.2$244dda20@zahav.net.il> <20041210230603.GA23419@nevyn.them.org> <01c4df10$Blat.v2.2.2$6f63d1a0@zahav.net.il> <20041210233700.GA24439@nevyn.them.org> <01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il> <200412111433.iBBEXqpN007235@elgar.sibelius.xs4all.nl> <20041211163652.GB13865@nevyn.them.org> X-SW-Source: 2004-12/txt/msg00314.txt.bz2 Date: Sat, 11 Dec 2004 11:36:52 -0500 From: Daniel Jacobowitz > Adding hacks around hacks, like we've been doing to support threads on > Linux for quite some time now is defenitely not a good idea. Mark, would you please stop saying this? I don't believe it to be true any more. If you think it's still accurate, please point me at specific hacks around hacks, and let's see if we can get rid of them now. Sorry Daniel, I know you've done some really good work with regard to threads in the kernel. I guess I'm still somewhat frustrated about the situation back when I wrote the initial Linux LWP layer. Back then the attitude of the kernel developers was basically: "We won't complicate the kernel with support for debuggers, solve everything from userland!". That said, there is just too much code in linux-nat.c. If you compare the code necessary to implement to_wait and to_resume that's there with the amount of code in inf-ttrace.c, you see what I mean. Most of the code is present because we need to stop each thread individually by sending it a SIGSTOP. Things become so much simpler if the kernel would provide an interface to stop them all in one go that doesn't interfere with signal delivery... I admit there are some peculiarities related to stopping all threads. But most of them are related to very real situations that we want to be able to debug: two threads receiving a signal at the same time, hitting different breakpoints at the same time, et cetera. Life with threads is just more complicated. Some platforms do the complicated bits in the kernel, and Linux chose to expose an LWP-oriented interface rather than a whole-process oriented interface so we have to do the complicated bits in userspace. That is not going to change, because the Linux design philosophy for threading is that they are just a special kind of process; Linux has no concept of "the whole process" and will not be adding one. This has been discussed from time to time on the linux-kernel list. [There is some correlation to the POSIX threading concept of a process, for the purpose of POSIX-compliant signal delivery, but that's the extent of it.] I still think this is wrong. The very fact that these proceses share a virtual memory space means that they're grouped together. The kernel shouldn't deny that. But even if folks don't want to support freezing that memory space atomically (at least to the observer), we really need a way to stop each process individually that doesn't interfere with signal delivery. I sincerely believe that we'll keep seeing thread-related problems if it isn't possible to stop threads while keeping all signals pending. And I'm busily (at work) improving platform support for NPTL; one of my goals is to someday rip all the LinuxThreads support code out of GDB. But it's going to be a long time before that's a viable option - at least a couple of years from now. That's no more friendly than dropping support for all but the newest kernel. And we'll need some of that code to provide quality support for debugging multiple processes simultaneously, or to support debugging applications which use clone() directly. Your work is very much appreciated. Mark