From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1574 invoked by alias); 4 Aug 2008 02:52:25 -0000 Received: (qmail 1566 invoked by uid 22791); 4 Aug 2008 02:52:25 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Aug 2008 02:51:42 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw1.br.ibm.com (Postfix) with ESMTP id EDF0232C097 for ; Sun, 3 Aug 2008 23:23:08 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m742pSRN1949746 for ; Sun, 3 Aug 2008 23:51:33 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m742pMxk031719 for ; Sun, 3 Aug 2008 23:51:22 -0300 Received: from [9.18.199.243] ([9.18.199.243]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m742p8ni031549; Sun, 3 Aug 2008 23:51:15 -0300 Subject: Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support From: Thiago Jung Bauermann To: Eli Zaretskii Cc: tromey@redhat.com, gdb-patches@sources.redhat.com In-Reply-To: References: <20080528205921.GA2969@caradoc.them.org> <20080615181833.uxmo25mg0kko40kw@imap.linux.ibm.com> <1216107418.14956.27.camel@localhost.localdomain> <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> <1216653969.31797.6.camel@localhost.localdomain> <20080726173508.GA16470@caradoc.them.org> Content-Type: text/plain Date: Mon, 04 Aug 2008 02:52:00 -0000 Message-Id: <1217818243.9336.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit 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/msg00045.txt.bz2 On Sat, 2008-07-26 at 22:17 +0300, Eli Zaretskii wrote: > Here's something that should explain what I have in mind (details > might be factually incorrect): Thanks for this text. I think it can be mostly used, except... > > When executing the @code{python} command, Python exceptions uncaught > within the Python code are translated to calls to @value{GDBN} > error-reporting mechanism, which terminates the currently executing > command and prints 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: ... it is not necessarily true that GDB will terminate the currently executing command when the Python exception is converted to a GDB exception. If the Python script is extending some GDB subsystem (one of our goals), that subsystem can catch the exception and deal with it in another way. So for this part I suggest: ... are translated to calls to @value{GDBN} error-handling mechanism, which depending on the context of the Python script can either deal with the error in a subsystem-specific way, or terminate the currently executing command ... What do you think? -- []'s Thiago Jung Bauermann IBM Linux Technology Center