Re: set_value_component_location in apply_val_pretty_printer

["Ulrich Weigand" <uweigand@de.ibm.com>]

Yao Qi wrote:

> I don't understand this piece of code in apply_val_pretty_printer,
> why do we need to call set_value_component_location?
> 
>   set_value_component_location (value, val);
>   /* set_value_component_location resets the address, so we may
>      need to set it again.  */
>   if (VALUE_LVAL (value) !=3D lval_internalvar
>       && VALUE_LVAL (value) !=3D lval_internalvar_component
>       && VALUE_LVAL (value) !=3D lval_computed)
>     set_value_address (value, address + embedded_offset);
> 
> It was added by Tom in
> https://sourceware.org/ml/gdb-patches/2010-06/msg00132.html
> There wasn't much information in email and ChangeLog.

This the case I mentioned in my recent email to Pedro here,
where we want to create a subobject of the original object.

The problem with the value printing routines is that if you
are printing an object of some complicated type, the routines
recurse through subobjects.  However, you don't always want
to allocate a new value object for the current subobject
just so you can make the recursive call.

That's why all the val_print routines not just receive the
original value object (which remains unchanged even while
recursing through subobjects), but also an idenfication of
the subobject that is to be processed: this is a pair of
offset and type, and means, the subobject of type "type"
starting at offset "offset" within the larger object.

This works fine for the various routines in the valprint
files.  However, when using a Python pretty-printer, you
can only pass a normal value object; the pretty-printer
is not set up to handle subobjects.  Therefore, at this
point apply_val_pretty_printer does actually have to
allocate a new value object to hold the subobject.

It's reasonably simple to just create a new object of
the correct type and having the correct contents.  However,
some of the value printers also want to use the value's
*location*.  Just allocating a fresh object would have
no location information.   That's why the code above
calls set_value_component_location to set the location
of the new value to the same as the location of the old.

But this isn't really correct either, since we need the
location of the *subobject*.  Now if the value resides
in inferior memory, we can get there simply by adding
the offset to the value address.  But that's not actually
correct for values with other location types.

I think we should either add an offset parameter to
set_value_component_location, and have it attempt to
do the best thing possible to describe the subobject
location, or maybe even provide a function that creates
the subobject directly in one go, along the lines of
value_primitive_field, except not based on struct
types but simply using an offset and subobject type.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com