diff options
author | Tom Tromey <tom@tromey.com> | 2022-06-05 07:42:12 -0600 |
---|---|---|
committer | Tom Tromey <tom@tromey.com> | 2022-07-08 14:14:58 -0600 |
commit | d19ca0b35c9536210c5e8bd30504489b7439f51f (patch) | |
tree | a488182e25b0d0a16eea68ab816c986988c28cfd /gprofng/src | |
parent | fa17a6814113ac22d8059d61514aa2c6e29b0aae (diff) | |
download | gdb-d19ca0b35c9536210c5e8bd30504489b7439f51f.zip gdb-d19ca0b35c9536210c5e8bd30504489b7439f51f.tar.gz gdb-d19ca0b35c9536210c5e8bd30504489b7439f51f.tar.bz2 |
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
Diffstat (limited to 'gprofng/src')
0 files changed, 0 insertions, 0 deletions