From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1450 invoked by alias); 1 Feb 2012 08:32:23 -0000 Received: (qmail 1441 invoked by uid 22791); 1 Feb 2012 08:32:22 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Feb 2012 08:32:00 +0000 Received: by vcbf13 with SMTP id f13so927100vcb.0 for ; Wed, 01 Feb 2012 00:32:00 -0800 (PST) Received: by 10.52.240.144 with SMTP id wa16mr5010587vdc.94.1328085120145; Wed, 01 Feb 2012 00:32:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.3.130 with HTTP; Wed, 1 Feb 2012 00:31:40 -0800 (PST) In-Reply-To: References: From: Kevin Pouget Date: Wed, 01 Feb 2012 08:32:00 -0000 Message-ID: Subject: Re: RFA: fix PR python/13599 To: Doug Evans , Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-02/txt/msg00000.txt.bz2 On Wed, Feb 1, 2012 at 12:22 AM, Doug Evans wrote: > On Tue, Jan 31, 2012 at 2:01 PM, Tom Tromey wrote: >> This fixes PR python/13599. >> >> The bug is that there is no way to get the line number in the source at >> which a symbol was defined, even though gdb tracks this information. >> >> This patch changes gdb.Symbol to add a new 'line' attribute. >> >> This requires a doc review. >> >> Built and regtested on x86-64 Fedora 15. >> >> Tom >> >> 2012-01-31 =A0Tom Tromey =A0 >> >> =A0 =A0 =A0 =A0PR python/13599: >> =A0 =A0 =A0 =A0* python/py-symbol.c (sympy_line): New function. >> =A0 =A0 =A0 =A0(symbol_object_getset): Add "line". > > 'tis ok with me. > > One comment though. > The first thing that come to mind, as a user, is "Well, if I can get > the line number from the symbol, why do I have to look elsewhere to > get the file name?" > The reason is an internal gdb implementation detail that we expose in > python. IWBN if symbol tables were more nebulous entities - we might > want the freedom to change them a bit. =A0[Not that we necessarily can > change things now, but I think it's something we should keep in mind.] I was curious about the difference between your new method and this one: > def whereis(arg): > symbols =3D gdb.decode_line(arg) > for sal in symbols: > if sal is not None and sal.symtab is not None: > print "'%s' is at %s%s, line %s" % (arg, sal.pc !=3D 0 and "0= x%x " % sal.pc or "", sal.symtab.filename, sal.line) (I wrote this code before learning about `info line ...`) Actually, the difference between Symbol, Symtab and Symtab_and_line is still a bit obscure to me, I'm not sure that the documentation really explains the meaning of these classes, but just what they do (or maybe I missed something): > A gdb.Symbol object has the following attributes: ... > A gdb.Symtab_and_line object has the following attributes: ... Kevin