aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-03-10 10:49:05 +0000
committerAndrew Burgess <aburgess@redhat.com>2023-03-30 10:25:46 +0100
commitf4d9bc8356ebee51b91d6144acdd49a572c6aba6 (patch)
treee876f9ced5c4daee5142e32798aa55aa24ef44dd
parentdf4447e4c43e105bd6366081a07447506506f78b (diff)
downloadgdb-f4d9bc8356ebee51b91d6144acdd49a572c6aba6.zip
gdb-f4d9bc8356ebee51b91d6144acdd49a572c6aba6.tar.gz
gdb-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>
-rw-r--r--gdb/value.c9
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
}