[Bug python/27000] New: gdb.block_for_pc should accept a gdb.Value argument

[Bug python/27000] New: gdb.block_for_pc should accept a gdb.Value argument

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27000

            Bug ID: 27000
           Summary: gdb.block_for_pc should accept a gdb.Value argument
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: python
          Assignee: unassigned at sourceware dot org
          Reporter: jwakely.gcc at gmail dot com
  Target Milestone: ---

I've come up with this wrapper for gdb.block_for_pc:

def block_for_function_pointer(f):
    "Find the gdb.Block corresponding to a function pointer in a gdb.Value"

    # Turn the function pointer into an actual address.
    # This is needed to unpack ppc64 function descriptors.
    f = f.dereference().address

    if sys.version_info[0] == 2:
        # Need to use long for Python 2, because int on 64-bit big-endian
        # values raises gdb.error saying "Cannot convert value to int."
        f = long(f)
    else:
        f = int(f)

    try:
        # The GDB manual says this returns None if it fails, but it can raise
        # RuntimeError saying "Cannot locate object file for block."
        return gdb.block_for_pc(f)
    except:
        return None


This is horrible, and IMHO none of it should be necessary.

For powerpc64 a C pointer to function cannot be converted directly to an
integer (it's a "function descriptor") so I use f.dereference().address to do
that.

Then converting to an int has to be done differently for Python 2 (for RHEL 7)
and Python 3. Using int(f) fails for some values with Python 2, raising an
exception, so you have to use long(f). But long doesn't exist in Python 3.

In Python 2 the built-in int() function is supposed to automatically return a
long if the value doesn't fit in int. It would be useful if that happened when
calling it with a gdb.Value argument. That would allow int(f) to work for Py2
and Py3.

Finally, I need to handle exceptions from gdb.block_for_pc even though the
manual suggests it will return None if it fails.

Life would be much easier if a gdb.Value could be passed directly to 
gdb.block_for_pc. The value's gdb.Type should be checked to ensure it's a
suitable type (maybe just function pointers, but maybe void* should be allowed
too). That could presumably do the adjustment from function descriptor to
function address, if needed by the target ABI.

So to summarise:

- Calling int with gdb.Value should not raise an exception if long(v) would
work instead, just do that.

- gdb.block_for_pc should not raise exceptions for invalid values, or the docs
should be fixed.

- gdb.block_for_pc should just accept a gdb.Value of suitable type, and Do The
Right Thing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/27000] gdb.block_for_pc should accept a gdb.Value argument

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27000

--- Comment #1 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to Jonathan Wakely from comment #0)
> - Calling int with gdb.Value should not raise an exception if long(v) would
> work instead, just do that.
> 
> - gdb.block_for_pc should not raise exceptions for invalid values, or the
> docs should be fixed.

Actually it looks like these two are already done for GDB 10.1, I must have
tested with the wrong version, sorry.

But it would still be easier if I could use a gdb.Value directly.

Testcase:

int function ()
{
  int (*p)() = &function;
  return 0;
}
int main()
{
  return function(1);
}

On ppc64 running CentOS 7, with the system Python (2.7) and GDB 10.1 I get:

(gdb) start
Starting program: /home/jwakely/tmp/a.out 

Temporary breakpoint 2, main () at b.c:8
8         return function(1);
(gdb) step
function () at b.c:3
3         int (*p)() = &function;
(gdb) n
4         return 0;
(gdb) py p = gdb.parse_and_eval('p')
(gdb) py print p
@0x1001feb8: 0x10000550 <function>
(gdb) py b = gdb.block_for_pc(p)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/jwakely/gcc/gdb-10.1/share/gdb/python/gdb/__init__.py", line 207,
in block_for_pc
    return current_progspace().block_for_pc(pc)
TypeError: must be integer<K>, not gdb.Value
Error while executing Python code.
(gdb) py b = gdb.block_for_pc(int(p))
(gdb) py print(b)
None
(gdb) py b2 = gdb.block_for_pc(int(p.dereference().address))
(gdb) py print(b2)
<gdb.Block object at 0x3fff9d797db0>
(gdb) py print(b2.function.name)
function


Using the CentOS 7 system GDB 7.6 it was worse:

(gdb) start
Temporary breakpoint 1 at 0x1000059c: file b.c, line 8.
Starting program: /home/jwakely/tmp/a.out 

Temporary breakpoint 1, main () at b.c:8
8         return function(1);
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.ppc64
(gdb) step
function () at b.c:3
3         int (*p)() = &function;
(gdb) n
4         return 0;
(gdb) py p = gdb.parse_and_eval('p')
(gdb) py print(p)
@0x1001feb8: 0x10000550 <function>
(gdb) py int(p)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
gdb.error: Cannot convert value to int.
Error while executing Python code.
(gdb) py b = gdb.block_for_pc(p)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: must be integer<K>, not gdb.Value
Error while executing Python code.
(gdb) py b = gdb.block_for_pc(long(p))
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RuntimeError: Cannot locate object file for block.
Error while executing Python code.
(gdb) py b = gdb.block_for_pc(long(p.dereference().address)) ; print
b.function.name
function


The reason block_for_pc(long(p)) fails is that long(p) doesn't give the actual
address of the function:

(gdb) py print p
@0x1001feb8: 0x10000550 <function>
(gdb) py print "0x%x" % long(p.dereference().address)
0x10000550
(gdb) py print "0x%x" % long(p)
0x1001feb8

Presumably if a gdb.Value was passed to gdb.block_for_pc it could do that
automatically.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/27000] gdb.block_for_pc should accept a gdb.Value argument

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27000

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
We should probably audit all uses of PyArg_ParseTuple with
GDB_PY_LLU_ARG and change them all to accept a Value as well.
Though... I wonder if there's some more built-in way to do this, 
like a special method.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/27000] gdb.block_for_pc should accept a gdb.Value argument

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27000

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-06-04
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Tom Tromey from comment #2)
> We should probably audit all uses of PyArg_ParseTuple with
> GDB_PY_LLU_ARG and change them all to accept a Value as well.
> Though... I wonder if there's some more built-in way to do this, 
> like a special method.

I looked and, although 'nb_int' exists, gdb already sets this
and PyArg_ParseTuple doesn't seem to use it.
Seems like

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/27000] gdb.block_for_pc should accept a gdb.Value argument

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27000

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
I have a patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/27000] gdb.block_for_pc should accept a gdb.Value argument

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27000

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d19ca0b35c9536210c5e8bd30504489b7439f51f

commit d19ca0b35c9536210c5e8bd30504489b7439f51f
Author: Tom Tromey <tom@tromey.com>
Date:   Sun Jun 5 07:42:12 2022 -0600

    Accept gdb.Value in more Python APIs

    PR python/27000 points out that gdb.block_for_pc will accept a Python
    integer, but not a gdb.Value.  This patch corrects this oversight.

    I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use
    get_addr_from_python instead.  I also looked at uses of GDB_PY_LL_ARG,
    but those seemed relatively unlikely to be useful with a gdb.Value, so
    I didn't change them.  My thinking here is that a Value will typically
    come from inferior memory, and something like a line number is not too
    likely to be found this way.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27000

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/27000] gdb.block_for_pc should accept a gdb.Value argument

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27000

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |13.1

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.