From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2528 invoked by alias); 10 Apr 2008 15:37:58 -0000 Received: (qmail 2475 invoked by uid 22791); 10 Apr 2008 15:37:58 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Apr 2008 15:37:37 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5D2A5980F7; Thu, 10 Apr 2008 15:37:36 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 36F1D98060; Thu, 10 Apr 2008 15:37:36 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JjyqF-0007bZ-6y; Thu, 10 Apr 2008 11:37:35 -0400 Date: Thu, 10 Apr 2008 15:39:00 -0000 From: Daniel Jacobowitz To: Jan Kratochvil Cc: Doug Evans , GDB Patches , mark.kettenis@xs4all.nl, Roland McGrath Subject: Re: [patch] Fix Linux attach to signalled/stopped processes Message-ID: <20080410153735.GD21662@caradoc.them.org> Mail-Followup-To: Jan Kratochvil , Doug Evans , GDB Patches , mark.kettenis@xs4all.nl, Roland McGrath References: <20080401223012.GA14076@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080401223012.GA14076@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00195.txt.bz2 [Roland, job control question for you in here. I'm not sure who else to ask...] On Wed, Apr 02, 2008 at 12:30:12AM +0200, Jan Kratochvil wrote: > The condition whether the detached process (previously attached as stopped) > should be left stopped or running is not intuitive there now, it is Red Hat > patches backward compatible but IMO it should rather ask the user (with > a default of leaving it stopped). Yes, I don't like the changed behavior of detach. I think it would be more intuitive if detach always resumed, and the disconnect command worked for native debugging. Although that leaves gdbserver out in the cold (disconnect already has meaning there). So maybe it should be detach --stopped? For the FSF version we can address this separately from the attach bug. I have another idea to solve the attach problem that does not involve redelivering signals - use WNOHANG in the initial wait if /proc already shows the process as stopped. There shouldn't be a race if this is done after we PTRACE_ATTACH. But I got hung up trying to figure out what was going on with testing... If I run attach-stopped from your testcase in a shell, then send it a stop signal using kill from another window, stock GDB fails to attach to it - just as I'd expect, that's the bug we're discussing. But if I run the attach-stopped.exp test script this part works fine. It turns out that if we spawn the program in expect (even at the expect1.1> prompt, by hand) instead of using a shell with job control, GDB can attach to it just fine. In both cases the kernel reports the process as stopped. The difference in ps is the "s+": drow 28162 0.0 0.0 6152 376 pts/50 Ts+ 11:19 0:00 ./gdb.threads/attach-stopped drow 28179 0.0 0.0 6152 376 pts/51 T 11:20 0:00 ./gdb.threads/attach-stopped There's no difference in /proc/pid/status at all, besides the PIDs. The "s" means session leader, the "+" means foreground process group. 28162 is the one run from expect. Any idea why this makes a difference? Kernel version is 2.6.24, if that matters. If we could get the foreground process group behavior all the time, then we don't even need to change GDB. But I don't know if that's right since I don't understand how it occurs. -- Daniel Jacobowitz CodeSourcery