| commit | d19ca0b35c9536210c5e8bd30504489b7439f51f | |
| author | Tom Tromey <tom@tromey.com> | |
| Sun, 5 Jun 2022 13:42:12 +0000 (5 07:42 -0600) | ||
| committer | Tom Tromey <tom@tromey.com> | |
| Fri, 8 Jul 2022 20:14:58 +0000 (8 14:14 -0600) | ||
| tree | a488182e25b0d0a16eea68ab816c986988c28cfd | treesnapshot (tar.gz zip) |
| parent | fa17a6814113ac22d8059d61514aa2c6e29b0aae | commitdiff |
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
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