This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] New function value_has_address


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.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]