From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11882 invoked by alias); 5 Aug 2008 18:23:48 -0000 Received: (qmail 11873 invoked by uid 22791); 5 Aug 2008 18:23:48 -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; Tue, 05 Aug 2008 18:23:08 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id C1A9E80001; Tue, 5 Aug 2008 18:23:06 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 6A8B8983A9; Tue, 5 Aug 2008 18:23:06 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KQRBZ-0001uS-AB; Tue, 05 Aug 2008 14:23:05 -0400 Date: Tue, 05 Aug 2008 18:23:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support Message-ID: <20080805182305.GA6840@caradoc.them.org> Mail-Followup-To: Eli Zaretskii , bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com References: <1217818243.9336.7.camel@localhost.localdomain> <20080804121451.GA13640@caradoc.them.org> <20080805020754.GA17244@caradoc.them.org> <20080805121908.GA17219@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-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-08/txt/msg00081.txt.bz2 On Tue, Aug 05, 2008 at 09:10:04PM +0300, Eli Zaretskii wrote: > > Date: Tue, 5 Aug 2008 08:19:08 -0400 > > From: Daniel Jacobowitz > > Cc: bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com > > > I'm not sure this change is for the best: you've eliminated only one > > > of the two uses of "command" in this text, which just obfuscates the > > > text a little (what is it exactly in GDB that does not handle the > > > error, and if it isn't a command that invoked "python", why do we > > > terminate a command?). > > > > Is s/command/operation/ acceptable? > > No objections, but what problem would that solve? Your comment about terminating a command if something other than a command invoked Python. We terminate whatever it was that invoked Python. Operation is a general term ("we're doing something"), which does not have the risk associated with "command" which has a specific meaning in GDB. None of this is restricted to the context of commands. > > If any part of GDB handles the error, the error is swallowed. > > Otherwise it drifts upwards through the call stack, terminating > > function calls as it goes. It's always caught if it reaches the main > > command loop, but there are lots of other places too. > > Yes, I know, but again: how does this help to make the above passage > right? I'm afraid you've lost me :-( I need a little help - what's not right about it? You said it was confusing, not that it was wrong, so I tried to make it clearer. To the best of my technical and writing ability, the version above accurately describes GDB's behavior. And I think it's clear, too. To reduce quoting depth (I have trouble following discussion when it gets too deep), here it is again. When executing Python code, uncaught Python exceptions are translated to calls to the @value{GDBN} error-reporting mechanism. If @value{GDBN} does not handle the error, it will terminate the current operation and print an error message containing the Python exception name, the associated value, and the Python call stack backtrace at the point where the exception was raised. Example: -- Daniel Jacobowitz CodeSourcery