From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19993 invoked by alias); 2 Feb 2010 20:14:31 -0000 Received: (qmail 19985 invoked by uid 22791); 2 Feb 2010 20:14:30 -0000 X-SWARE-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BAYES_50,KAM_STOCKGEN,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Feb 2010 20:14:24 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0KX800I00DHJW300@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Tue, 02 Feb 2010 22:14:21 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.67.249]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KX800GRDDJWLN70@a-mtaout23.012.net.il>; Tue, 02 Feb 2010 22:14:21 +0200 (IST) Date: Tue, 02 Feb 2010 20:14:00 -0000 From: Eli Zaretskii Subject: Re: [patch][python] Add symbol, symbol table and frame block support to GDB API In-reply-to: <4B67FD58.5050504@redhat.com> To: Phil Muldoon Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83hbpzgztm.fsf@gnu.org> References: <4B66DA35.7080701@redhat.com> <83sk9khe3b.fsf@gnu.org> <4B67FD58.5050504@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/msg00046.txt.bz2 > Date: Tue, 02 Feb 2010 10:24:24 +0000 > From: Phil Muldoon > CC: gdb-patches ml > > >> +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? > >> +@value{GDBN} represents the name of every variable, function and type > >> +as a symbol (@pxref{Symbols, ,Examining the Symbol Table}). > > > > I think, from the GDB user POV, a name of a variable, function, and > > type is just a string, not a symbol. > > But in the context of the Python API, they are represented as symbols? How should I word this? How about @value{GDBN} represents every variable, function and type as a an entry in a symbol table. > >> +@item SYMBOL_LOC_REF_ARG > >> +Value address is an offset in arglist. > > > > I couldn't understand what this means. > > > Yeah, this is a concept expressed in the comments of the code. Where? I don't see it in the patch you submitted. > > Do we need a NEWS entry for this? > > Not sure. From my point of view I am merging code from Archer to FSF > GDB. I'll happily write one up if you think we need one? What do you > think? Something like The GDB Python API now has access to symbols, symbol tables, and frame's code blocks. Thanks.