From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24522 invoked by alias); 7 May 2012 19:36:59 -0000 Received: (qmail 24309 invoked by uid 22791); 7 May 2012 19:36:57 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 May 2012 19:36:41 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M3O000003SMDX00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Mon, 07 May 2012 22:36:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3O00LZI3T2VEV0@a-mtaout22.012.net.il>; Mon, 07 May 2012 22:36:39 +0300 (IDT) Date: Mon, 07 May 2012 19:36:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] - Exposing find_pc_line through Python API In-reply-to: To: Siva Chandra Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <8362c73huz.fsf@gnu.org> References: 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: 2012-05/txt/msg00189.txt.bz2 > Date: Mon, 7 May 2012 23:41:25 +0530 > From: Siva Chandra > > I wanted a way to get the actual line number given a PC value using > the Python API. The currently available Symtab_and_line.line gives > the line number which the user thinks the current execution is, but > not the actual. That "user thinks the execution is at" notion is far from being clear to me. See below. > Attached is a patch which adds gdb.find_pc_line corresponding to the > C function find_pc_line. Thanks. > +@defun gdb.find_pc_line (pc [, actual]) > +Return the @code{gdb.Symtab_and_line} object corresponding to the > +@var{pc} value. If @var{actual} is @code{True}, it returns the ^^^^^^^^^^ "return", for consistency with the first sentence. > +@code{gdb.Symtab_and_line} object with the actual line corresponding > +to the pc value. Otherwise, it returns the @code{gdb.Symtab_and_line} ^^^^^^^^^^ Likewise. > +The difference between @var{actual} being @code{True} or @code{False} > +can be illustrated with an example. Let a call to a function @code{func} > +be on line 20 in a C source file as > + > +@smallexample > +18 ... > +19 > +20 func (); > +21 > +22 return 0; > +23 > +24 ... > +@end smallexample > + > +After executing @value{GDBN} commands @code{step} followed by @code{up} > +at line 20, the actual value of the @code{PC} register should correspond > +to the next code line at line 22. However, since the function > +@code{func} has not yet been executed, the user feels that the execution > +is still at line 20 (the call site) in the caller. If I were that user, I would "feel" that the execution is at the first line (or maybe in the prologue) of 'func', since PC is (in my mind) unaffected by commands that walk the call stack. And if you are talking about the value of PC saved in the frame of the caller of 'func', then saying that line 22 is the "actual" location is again confusing, because execution did not yet reach that point. So I have hard time understanding why we need the distinction. And since you say that the current Symtab_and_line.line gives the second alternatives, I'm confused even more. It's possible that I'm the only confused person here, but in that case, at least the example should be fixed to show and explain the distinction more clearly and unequivocally, and also in which situations the "actual" value is useful.