From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18628 invoked by alias); 5 Feb 2010 11:05:54 -0000 Received: (qmail 18618 invoked by uid 22791); 5 Feb 2010 11:05:53 -0000 X-SWARE-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,BAYES_20,KAM_STOCKGEN,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Feb 2010 11:05:47 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KXD004007YBQE00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Fri, 05 Feb 2010 13:04:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.67.249]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KXD001QM83VJIB0@a-mtaout20.012.net.il>; Fri, 05 Feb 2010 13:04:44 +0200 (IST) Date: Fri, 05 Feb 2010 11:05:00 -0000 From: Eli Zaretskii Subject: Re: [patch][python] Add symbol, symbol table and frame block support to GDB API In-reply-to: <4B69E2C6.3090509@redhat.com> To: Phil Muldoon Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83r5p0eyer.fsf@gnu.org> References: <4B66DA35.7080701@redhat.com> <83sk9khe3b.fsf@gnu.org> <4B67FD58.5050504@redhat.com> <83hbpzgztm.fsf@gnu.org> <4B69E2C6.3090509@redhat.com> 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: 2010-02/txt/msg00164.txt.bz2 > Date: Wed, 03 Feb 2010 20:55:34 +0000 > From: Phil Muldoon > CC: gdb-patches@sourceware.org > > This is a multi-part message in MIME format. > --------------050506000002080100010500 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > On 02/02/2010 08:14 PM, Eli Zaretskii wrote: > > >>>> +All of the name-scope contours of a program are represented as 'block' > >>> > >>> What are "contours"? Is this a widespread enough terminology to be > >>> understood without defining it first? If not, I suggest to define it. > >> > >> > >> I really agonized over the whole block description, as there is no (as > >> far as I know) analogue to the GDB CLI for blocks. It's revealing an > >> API that GDB uses to manipulate blocks in a frame. I could use some > >> help making this more palatable enough to the consumer of the API, > >> over trying to teach the user compiler/runtime semantics (which is not > >> the purpose of the GDB manual). What do you think? > > > > How about if you tell what you want in the most technical way you > > think about these issues, disregarding the fact that it's for GDB > > users, and I will then rephrase it to be palatable to mere mortals? > > > I've attached an updated patch. What do you think? It's good, thanks. I have only a couple of comments: > +@defivar Symbol is_argument > +Is @code{True} if the symbol is an argument of a function. I'd prefer to drop the "Is" part altogether, here and elsewhere. > +@findex SYMBOL_LOC_ARG > +@findex gdb.SYMBOL_LOC_ARG > +@item SYMBOL_LOC_ARG > +Value is an argument. The comment in the source says: /* It's an argument; the value is at SYMBOL_VALUE offset in arglist. */ Should we expand the above description by adding some text from the comment? > +@findex SYMBOL_LOC_REF_ARG > +@findex gdb.SYMBOL_LOC_REF_ARG > +@item SYMBOL_LOC_REF_ARG > +Value address is an offset in arglist. The comment in the code seems to be a continuation of the previous comment (shown above). Again, perhaps we should say more. Can you or someone else explain what these constants mean, i.e. say a bit more than the comment says?