From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18965 invoked by alias); 15 Mar 2009 19:21:18 -0000 Received: (qmail 18949 invoked by uid 22791); 15 Mar 2009 19:21:17 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout2.012.net.il (HELO mtaout2.012.net.il) (84.95.2.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Mar 2009 19:21:08 +0000 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KGK00B00AAASS00@i_mtaout2.012.net.il> for gdb-patches@sourceware.org; Sun, 15 Mar 2009 21:21:52 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.228.91]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KGK009F0B4FVSF1@i_mtaout2.012.net.il>; Sun, 15 Mar 2009 21:21:52 +0200 (IST) Date: Sun, 15 Mar 2009 19:30:00 -0000 From: Eli Zaretskii Subject: Re: [rfc] python API exposing inferior's frame stack. In-reply-to: <1237133466.316.16.camel@localhost.localdomain> To: Thiago Jung Bauermann Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <1236706351.11106.17.camel@localhost.localdomain> <1237133466.316.16.camel@localhost.localdomain> 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: 2009-03/txt/msg00238.txt.bz2 > From: Thiago Jung Bauermann > Cc: gdb-patches@sourceware.org > Date: Sun, 15 Mar 2009 13:11:06 -0300 > > El mar, 10-03-2009 a las 21:35 +0200, Eli Zaretskii escribió: > > > This patch allows a Python script to work with the inferior's frame > > > stack. For now, the only "entry point" for this API is the > > > gdb.selected_frame function. > > > > Thanks. I have a few comments about the documentation part of the > > patch. > > Thanks for the review. The comments which I don't reply to below were > addressed. > > > > +@defmethod Frame unwind_stop_reason > > > +Return an integer representing the reason why it's not possible to find > > > +frames older than this. > > > > "older"? You mean, higher in the call stack? > > I don't know, which direction is "higher in the call stack"? :-) > > > Is "older" widespread enough to be self-explanatory? > > "older" is the name of the Frame method used to get the previous frame > (where "previous" is the convention used in the GDB source code), so it > has a good chance of being clear to the user of the Python API. In any > case, I reworded it to: > > "Return an integer representing the reason why it's not possible to find > frames older (outer) than this." I prefer "frames previous to this one". We already use similar wording in frame_stop_reason_string. > This usage directly reflects the way things are done in the GDB > internals. Perhaps I should depart from it, remove gdb.find_pc_function > and gdb.Frame.address_in_block and directly provide a gdb.Frame.function > method which returns the gdb.Symbol object for the function > corresponding to the frame? > > It sounds like a better idea now that I think about it. But I'll have to > post a patch exposing inferior symbols before I can submit it upstream. > > I'll remove gdb.Frame.address_in_block for now, then. Sounds good, thanks. > > > +@defmethod Frame older > > > +Return the frame immediately older (outer) to this frame. > > > +@end defmethod > > > + > > > +@defmethod Frame newer > > > +Return the frame immetidaely newer (inner) to this frame. > > > +@end defmethod > > > > Suggest to use "higher" or "above" or "towards the outermost frame". > > Generally, try to use the terminology from the "Examining the Stack" > > chapter of the manual. > > IMHO, "inner" and "outer" are already conforming to the terminology from > the "Examining the Stack" chapter. It is a bit awkward to use "towards > the outermost frame" to describe these methods, e.g.: > > "Return the next frame in the direction towards the outermost frame." > > and > > "Return the next frame in the direction towards the innermost frame." > > Mmm... Now that I tried, doesn't sound too bad. But still I find my > original wording more direct and simpler to understand. What do you > think? We use "innermost" in the manual much more than "inner". You can also use "previous" and "next" if you like that better. Also note that there's a typo in the quoted fragment ("immetidaely"). Thanks.