This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] New function value_has_address
- From: Pedro Alves <palves at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, Simon Marchi <simon dot marchi at polymtl dot ca>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 28 Oct 2016 15:25:48 +0100
- Subject: Re: [PATCH] New function value_has_address
- Authentication-results: sourceware.org; auth=none
- References: <20161028140942.7049210B91A@oc8523832656.ibm.com>
On 10/28/2016 03:09 PM, Ulrich Weigand wrote:
> Pedro Alves wrote:
>> The value printing routines want to pass around a value address,
>> but since we actually pass the value pointer around nowadays too,
>> I think that parameter could be eliminated, and the result is
>> likely to be that value_address ends up called is much fewer
>> places where it doesn't really make sense.
> Agreed. I've done a quick check, and it seems except from
> recursively passing around the address value throughout
> the printing routines, there only a small number of actual
> uses of the address parameter:
> - print_unpacked_pointer, where we actually want to show that
> address to the user
> - cp_print_value routines (and similar code in p-valprint),
> where we want to load the contents of the superclass
> surrounding the current subclass from memory
> - Ada needs the address to call resolve_dynamic_type
> - The extension language printer (guile, python), where we
> want to create a subobject value at the embedded offset
> - A few more places in Ada also want to create the subobject
> value at the embedded offset
> I think for the first three, we should simply check right
> at the place where it is needed whether the original value
> has an address in inferior memory, and if not, just fail.
> For the cases where the subobject value is needed, I think
> we should provide a generic helper to compute the location
> at the embedded offset from the original value's location,
> depending on the location type. (And in those cases where
> this may not be possible, just default to unknown location.)
Thanks for investigating!
> B.t.w. the valaddr parameter likewise seems to be redundant
> now and probably ought to be eliminated as well.
Agreed. Getting rid of that one would allow creating
sparse value contents, btw. Currently we're forced to
always allocate a huge buffer for huge inferior values
exactly because these routines assume the value contents
are one single byte array.