From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14797 invoked by alias); 17 Mar 2008 16:49:12 -0000 Received: (qmail 14789 invoked by uid 22791); 17 Mar 2008 16:49:12 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Mar 2008 16:48:54 +0000 Received: (qmail 8029 invoked from network); 17 Mar 2008 16:48:52 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Mar 2008 16:48:52 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: Stop breakpoint commands from poping the target Date: Mon, 17 Mar 2008 16:49:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200803140802.34377.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803171648.51861.pedro@codesourcery.com> 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/msg00234.txt.bz2 A Saturday 15 March 2008 15:58:59, Vladimir Prus escreveu: > 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. > I don't know why we're doing that. Maybe it should have been an internal error, or maybe we'll find a case where an exception must not be caught there. It's not even a good job in doing the popping it either. The target is left in some undefined state. -- Pedro Alves