From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29090 invoked by alias); 15 Mar 2008 15:59:35 -0000 Received: (qmail 29077 invoked by uid 22791); 15 Mar 2008 15:59:32 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 15 Mar 2008 15:59:12 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JaYml-0001nw-JT for gdb-patches@sources.redhat.com; Sat, 15 Mar 2008 15:59:03 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Mar 2008 15:59:03 +0000 Received: from ghost by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Mar 2008 15:59:03 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: Stop breakpoint commands from poping the target Date: Sat, 15 Mar 2008 15:59:00 -0000 Message-ID: References: <200803140802.34377.pedro@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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-03/txt/msg00215.txt.bz2 Pedro Alves wrote: > This patch goes on top of Vladimir's pending async fixes patch. > > commands.exp triggers the problem this patch addresses, in > async mode. > > In that test, we have a watch on a local variable, and then we > add a command to that watch to print the local variable's > value. When the variable goes out of scope, gdb prints that, > and also runs the associated commands with the watch. Since > the variable is out of scope, and error is thrown. In sync > targets, the exception just ends the breakpoints command > processing, and goes on to proceed with the command loop. But in > async mode, the exception ends up in > inf-loop.c:inferior_event_handler/INF_REG_EVENT, which considers exceptions > fatal, and pops the target. The fix is to catch the exception earlier. Why do we pop the target in the first place? It does not seem like a good idea to do that if any exception is thrown. I actually agree that if breakpoint commands fail, it's not then end of world, and we can go on with continuations. But at the same time, popping target on any unhandled exception sounds a little bit drastic. - Volodya