This commit:
commit d1cab9876d
Date: Tue Sep 15 11:08:56 2020 -0600
Don't use gdb_py_long_from_ulongest
Introduced a regression when GDB is compiled with Python 2. The frame
filter API expects the gdb.FrameDecorator.function () method to return
either a string (the name of a function) or an address, which GDB then
uses to lookup a msymbol.
If the address returned from gdb.FrameDecorator.function () comes from
gdb.Frame.pc () then before the above commit we would always expect to
see a PyLong object.
After the above commit we might (on Python 2) get a PyInt object.
The GDB code does not expect to see a PyInt, and only checks for a
PyLong, we then see an error message like:
RuntimeError: FrameDecorator.function: expecting a String, integer or None.
This commit just adds an additional call to PyInt_Check which handle
the missing case.
I had already written a test case to cover this issue before spotting
that the gdb.python/py-framefilter.exp test also triggers this
failure. As the new test case is slightly different I have kept it
in.
The new test forces the behaviour of gdb.FrameDecorator.function
returning an address. The reason the existing test case hits this is
due to the behaviour of the builtin gdb.FrameDecorator base class. If
the base class behaviour ever changed then the return an address case
would only be tested by the new test case.
gdb/ChangeLog:
* python/py-framefilter.c (py_print_frame): Use PyInt_Check as
well as PyLong_Check for Python 2.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter-addr.c: New file.
* gdb.python/py-framefilter-addr.exp: New file.
* gdb.python/py-framefilter-addr.py: New file.
