Python Symbol API question/weirdness

Python Symbol API question/weirdness

[Evan Driscoll]

[I wrote most of this with 7.11, but I tried again with 8.0 and still
have the same problem. See below for more.]


I've got a toy program (can send out source and/or binary if it'd be
helpful) that calls raise(SIGTRAP) in it.

At that point, I can ask for a backtrace:

(gdb) bt
#0  0x00007ffff7a43428 in __GI_raise (sig=sig@entry=5)
...

and then use 'info symbol' to get some information based on that
address, and cross-check it with the symbol name that it gives back:

(gdb) info symbol  0x00007ffff7a43428
raise + 56 in section .text of /lib/x86_64-linux-gnu/libc.so.6
(gdb) info symbol raise
raise in section .text of /lib/x86_64-linux-gnu/libc.so.6
(gdb) python print(gdb.parse_and_eval("raise"))
{<text variable, no debug info>} 0x7ffff7a433f0 <__GI_raise>

I'm not sure the following is relevant, but just in case:

(gdb) print &raise
$2 = (<text variable, no debug info> *) 0x7ffff7a433f0 <__GI_raise>
(gdb) print &__GI_raise
$3 = (int (*)(int)) 0x7ffff7a433f0 <__GI_raise>


However, I can't look up that symbol in Python using lookup_global_symbol:

(gdb) python print(gdb.lookup_symbol("raise"))
(None, False)
(gdb) python print(gdb.lookup_global_symbol("raise"))
None

Setting a domain doesn't seem to help:

>>> ds = [gdb.SYMBOL_UNDEF_DOMAIN,
...       gdb.SYMBOL_VAR_DOMAIN,
...       gdb.SYMBOL_STRUCT_DOMAIN,
...       gdb.SYMBOL_LABEL_DOMAIN,
...       gdb.SYMBOL_VARIABLES_DOMAIN,
...       gdb.SYMBOL_FUNCTIONS_DOMAIN,
...       gdb.SYMBOL_TYPES_DOMAIN,
...       ]
>>> for d in ds: print(gdb.lookup_global_symbol("raise", d))
None
None
None
None
None
None
None

Does anyone have any idea what might be going on? I think I don't
actually need this to work, but I am curious what is going on. Maybe
something with symbol aliases?

With GDB 8.0 instead of 7.11, things change slightly but remain
largely the same. __GI_raise never shows up -- the backtrace just says
"raise" instead, and 'print __GI_raise' and 'info symbol __GI_raise'
both produce errors.

Thanks,
Evan

Re: Python Symbol API question/weirdness

[Pedro Alves]

On 06/16/2017 09:55 PM, Evan Driscoll wrote:

> Does anyone have any idea what might be going on? I think I don't
> actually need this to work, but I am curious what is going on. Maybe
> something with symbol aliases?

I think that you're seeing this because the Python API is only aware
of debug info symbols, while "raise" etc. above in your examples
are minimal symbols (i.e., elf symbols), as hinted by:

  $2 = (<text variable, no debug info> *) 0x7ffff7a433f0 <__GI_raise>
                        ^^^^^^^^^^^^^

Sounds like exposing minsyms to the Python layer would be useful.
I'm actually surprised it doesn't already expose them somehow.

Thanks,
Pedro Alves

Re: Python Symbol API question/weirdness

[Matt Rice]

On Tue, Jun 27, 2017 at 3:56 AM, Pedro Alves <palves@redhat.com> wrote:
> On 06/16/2017 09:55 PM, Evan Driscoll wrote:
>
>> Does anyone have any idea what might be going on? I think I don't
>> actually need this to work, but I am curious what is going on. Maybe
>> something with symbol aliases?
>
> I think that you're seeing this because the Python API is only aware
> of debug info symbols, while "raise" etc. above in your examples
> are minimal symbols (i.e., elf symbols), as hinted by:
>
>   $2 = (<text variable, no debug info> *) 0x7ffff7a433f0 <__GI_raise>
>                         ^^^^^^^^^^^^^
>
> Sounds like exposing minsyms to the Python layer would be useful.
> I'm actually surprised it doesn't already expose them somehow.

I think you can get some information about minsyms from decode_line
(gdb) py print(gdb.parse_and_eval("main"))
{<text variable, no debug info>} 0x4004f0 <main>
(gdb) py print('%02x' % gdb.decode_line("main")[1][0].pc)
4004f0