Re: RFA: fix PR python/13599

[Kevin Pouget <kevin dot pouget at gmail dot com>]

On Wed, Feb 1, 2012 at 12:22 AM, Doug Evans <dje@google.com> wrote:
> On Tue, Jan 31, 2012 at 2:01 PM, Tom Tromey <tromey@redhat.com> 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 ?Tom Tromey ?<tromey@redhat.com>
>>
>> ? ? ? ?PR python/13599:
>> ? ? ? ?* python/py-symbol.c (sympy_line): New function.
>> ? ? ? ?(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. ?[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 = 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 != 0 and "0x%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