diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-03-10 10:49:05 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-03-30 10:25:46 +0100 |
commit | f4d9bc8356ebee51b91d6144acdd49a572c6aba6 (patch) | |
tree | e876f9ced5c4daee5142e32798aa55aa24ef44dd /gdb/python/py-block.c | |
parent | df4447e4c43e105bd6366081a07447506506f78b (diff) | |
download | binutils-f4d9bc8356ebee51b91d6144acdd49a572c6aba6.zip binutils-f4d9bc8356ebee51b91d6144acdd49a572c6aba6.tar.gz binutils-f4d9bc8356ebee51b91d6144acdd49a572c6aba6.tar.bz2 |
gdb: have value_as_address call unpack_pointer
While refactoring some other code in gdb/python/* I wanted to merge
two code paths. One path calls value_as_address, while the other
calls unpack_pointer.
I suspect calling value_as_address is the correct choice, but, while
examining the code I noticed that value_as_address calls unpack_long
rather than unpack_pointer.
Under the hood, unpack_pointer does just call unpack_long so there's
no real difference here, but it feels like value_as_address should
call unpack_pointer.
I've updated the code to use unpack_pointer, and changed a related
comment to say that we call unpack_pointer. I've also adjusted the
header comment on value_as_address. The existing header refers to
some code that is now commented out.
Rather than trying to describe the whole algorithm of
value_as_address, which is already well commented within the function,
I've just trimmed the comment on value_as_address to be a brief
summary of what the function does.
There should be no user visible changes after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/python/py-block.c')
0 files changed, 0 insertions, 0 deletions