From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30728 invoked by alias); 5 Aug 2008 02:08:38 -0000 Received: (qmail 30244 invoked by uid 22791); 5 Aug 2008 02:08:37 -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 02:07:58 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D48D6983A9; Tue, 5 Aug 2008 02:07:55 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 92DC99839F; Tue, 5 Aug 2008 02:07:55 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KQBxq-0004eo-8r; Mon, 04 Aug 2008 22:07:54 -0400 Date: Tue, 05 Aug 2008 02:08: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: <20080805020754.GA17244@caradoc.them.org> Mail-Followup-To: Eli Zaretskii , bauerman@br.ibm.com, tromey@redhat.com, gdb-patches@sources.redhat.com References: <1216653969.31797.6.camel@localhost.localdomain> <20080726173508.GA16470@caradoc.them.org> <1217818243.9336.7.camel@localhost.localdomain> <20080804121451.GA13640@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/msg00068.txt.bz2 On Mon, Aug 04, 2008 at 10:48:46PM +0300, Eli Zaretskii wrote: > When executing the @code{python} command, Python exceptions > uncaught within the Python code are translated to calls to > @value{GDBN} error-reporting mechanism. If the command that called > @code{python} does not handle the error, @value{GDBN} will > terminate it 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: I think we've almost got it. The only problem I see with the above text is that it's focused on user commands, both "python" and others. This fits with the "Canned Sequences of Commands" usage which is what the first patch implements, but if we can say it more generally it may continue to be true as more patches go in. Here's some other scenarios I heard mentioned in conversation today: - Tab completion. Python code might be invoked when the user hits Tab in the middle of an expression. - "gdb --python", which Tom has implemented on the branch - no CLI interpreter involved, GDB just executes a Python script. - If Python code is used to discover some information about a stack frame, it might be invoked every time the program stops. So that gives me a paragraph like this, which I think is accurate. Does this look OK to you? 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 command 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