From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14353 invoked by alias); 9 May 2012 20:05:27 -0000 Received: (qmail 14344 invoked by uid 22791); 9 May 2012 20:05:24 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_NIX_SPAM,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; Wed, 09 May 2012 20:05:09 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M3R00D00UEKF500@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Wed, 09 May 2012 23:05:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3R00DAAUGJH200@a-mtaout22.012.net.il>; Wed, 09 May 2012 23:05:07 +0300 (IDT) Date: Wed, 09 May 2012 20:05: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: <83txzpyveh.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <8362c73huz.fsf@gnu.org> 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/msg00310.txt.bz2 > Date: Wed, 9 May 2012 13:05:01 +0530 > From: Siva Chandra > Cc: gdb-patches@sourceware.org > > > [1:text/plain Hide] > > Eli> If I were that user, I would "feel" that the execution is at the first > Eli> line (or maybe in the prologue) of 'func', since PC is (in my mind) > Eli> unaffected by commands that walk the call stack.  And if you are > Eli> talking about the value of PC saved in the frame of the caller of > Eli> 'func', then saying that line 22 is the "actual" location is again > Eli> confusing, because execution did not yet reach that point. > > Eli> So I have hard time understanding why we need the distinction.  And > Eli> since you say that the current Symtab_and_line.line gives the second > Eli> alternatives, I'm confused even more. > > Eli> It's possible that I'm the only confused person here, but in that > Eli> case, at least the example should be fixed to show and explain the > Eli> distinction more clearly and unequivocally, and also in which > Eli> situations the "actual" value is useful. > > The more I think about your comments, the more I feel that exposing > this 'actual' argument is not a good idea. I am now of the opinion > that the 'notcurrent' argument to the internal function find_pc_line > caters to a internal usage which depends on much more than just what > the user feels. Hence, I have modified the patch to remove the > 'actual' argument. The new version of the patch is attached. > > 2012-05-07 Siva Chandra Reddy > > Add a new function gdb.find_pc_line to the Python API. > * NEWS (Python Scripting): Add entry about the new function. > * python/python.c (gdbpy_find_pc_line): New function which > implements gdb.find_pc_line. > (GdbMethods): Add entry for the new function. > > doc/ > * gdb.texinfo (Basic Python): Add description about the function > gdb.find_pc_line OK for these two parts.