Bug in gdb.block_for_pc documentation?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in gdb.block_for_pc documentation?

Roman Popov
Hi all,
Looks like there is a bug in docs:

*"Function: gdb.block_for_pc (pc)*

*Return the innermost gdb.Block containing the given pc value. If the block
cannot be found for the pc value specified, the function will return None."*
https://sourceware.org/gdb/current/onlinedocs/gdb/Blocks-In-Python.html#Blocks-In-Python


Instead of returning None it throws runtime exception:

gdb.block_for_pc(0)
>> RuntimeError: Cannot locate object file for block.

Thanks,
Roman
Reply | Threaded
Open this post in threaded view
|

Re: Bug in gdb.block_for_pc documentation?

Simon Marchi
On 2017-12-21 20:15, Roman Popov wrote:

> Hi all,
> Looks like there is a bug in docs:
>
> *"Function: gdb.block_for_pc (pc)*
>
> *Return the innermost gdb.Block containing the given pc value. If the
> block
> cannot be found for the pc value specified, the function will return
> None."*
> https://sourceware.org/gdb/current/onlinedocs/gdb/Blocks-In-Python.html#Blocks-In-Python
>
>
> Instead of returning None it throws runtime exception:
>
> gdb.block_for_pc(0)
>>> RuntimeError: Cannot locate object file for block.
>
> Thanks,
> Roman

Thanks for reporting.  The corresponding code is here:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/python/py-block.c;h=840c842e85a3161685af3c1df2ecadbb16422979;hb=HEAD#l368

There are two failure cases, as far as I can see

1) We can't find a compilation unit for the given pc -> we throw an
exception
2) We can find a compilation unit for the given pc, but can't find a
corresponding block -> we return None

It's easy to trigger 1), you just call block_for_pc with a bad random
address.  I don't know how to trigger 2).  You would have to pass a pc
covered by a compilation unit, but not covered by a block, not sure when
that happens.

Now we have two choices, either we adapt the documentation to match the
reality, which easy.  Or we change the code to match the documentation,
which is harder because we risk breaking user scripts.

I don't really like the current situation, because the exception thrown,
RuntimeError, is very generic.  So if one uses "except RuntimeError" to
catch the case where block_for_pc fails, they risk catching other
things, like RecursionError, which derives from RuntimeError.  Returning
None, as the documentation suggests, would make more sense to me...

Simon