From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28304 invoked by alias); 29 Sep 2007 21:07:55 -0000 Received: (qmail 28296 invoked by uid 22791); 29 Sep 2007 21:07:55 -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; Sat, 29 Sep 2007 21:07:53 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D162B9832A; Sat, 29 Sep 2007 21:07:51 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 6374198109; Sat, 29 Sep 2007 21:07:51 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IbjXS-0002pM-Kd; Sat, 29 Sep 2007 17:07:50 -0400 Date: Sat, 29 Sep 2007 21:44:00 -0000 From: Daniel Jacobowitz To: Carl Shapiro Cc: Mark Kettenis , gdb@sourceware.org Subject: Re: Problems with hook-stop Message-ID: <20070929210750.GA10190@caradoc.them.org> Mail-Followup-To: Carl Shapiro , Mark Kettenis , gdb@sourceware.org References: <4dcb5abd0709260133h10aede86wb60a22094c8d9884@mail.gmail.com> <200709271127.l8RBRMPG017896@brahms.sibelius.xs4all.nl> <4dcb5abd0709271725v73cdf443q46fb43c985474c21@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4dcb5abd0709271725v73cdf443q46fb43c985474c21@mail.gmail.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00271.txt.bz2 On Thu, Sep 27, 2007 at 05:25:33PM -0700, Carl Shapiro wrote: > On 9/27/07, Mark Kettenis wrote: > > Since SIGTRAP has a very special meaning for debugging, it's probably > > unwise to play games like this. > > The problem I am having is not specific to SIGTRAP. You can replace > the interrupt instruction with a kill(2), providing any signal you'd > like as an argument. The stop hook will fails execute every other > time. Thank you for the test case. This was very useful. The problem is that we are still running the stop hook for the first stop when the program stops the second time. Basically, the stop "command" has been run again from inside the first hook-stop. There's a safety check for recursive hooks to prevent GDB blowing out its stack. If that weren't there you'd have an even more unpleasant bug to report. To fix this we would need to make a decision about what happens when a hook (or a breakpoint commands list, it's basically the same thing) runs the target. We don't want to necessarily abort the hook. Consider: define hook-stop call dump_state () echo done end Assuming there's no breakpoint or crash in dump_state, then we should run the function to completion and continue executing the stop hook. Maybe we should handle hooks and commands lists specially when they end in continue or signal. Basically a tail recursion optimization. I'm not going to try to do that right now, but I hope this explanation is helpful :-) -- Daniel Jacobowitz CodeSourcery