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 | |
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')
-rw-r--r-- | gdb/value.c | 9 |
1 files changed, 4 insertions, 5 deletions
diff --git a/gdb/value.c b/gdb/value.c index 757f925..eab1933 100644 --- a/gdb/value.c +++ b/gdb/value.c @@ -2621,9 +2621,8 @@ value_as_mpz (struct value *val) return result; } -/* Extract a value as a C pointer. Does not deallocate the value. - Note that val's type may not actually be a pointer; value_as_long - handles all the cases. */ +/* Extract a value as a C pointer. */ + CORE_ADDR value_as_address (struct value *val) { @@ -2662,7 +2661,7 @@ value_as_address (struct value *val) to COERCE_ARRAY below actually does all the usual unary conversions, which includes converting values of type `function' to `pointer to function'. This is the challenging conversion - discussed above. Then, `unpack_long' will convert that pointer + discussed above. Then, `unpack_pointer' will convert that pointer back into an address. So, suppose the user types `disassemble foo' on an architecture @@ -2723,7 +2722,7 @@ value_as_address (struct value *val) return gdbarch_integer_to_address (gdbarch, val->type (), val->contents ().data ()); - return unpack_long (val->type (), val->contents ().data ()); + return unpack_pointer (val->type (), val->contents ().data ()); #endif } |