Re: RFC: partially fix empty DW_OP_piece

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan>     int (*la_val_print) (struct type *type,
Jan>                          const gdb_byte *contents,
Jan>                          int embedded_offset, CORE_ADDR address,
Jan>                          struct ui_file *stream, int recurse,
Jan>                          const struct value_print_options *options);

Jan> There cannot be any `const gdb_byte *contents' for types with
Jan> DWARF_block* as their attribute (=TYPE_DYNAMIC from
Jan> archer-jankratochvil-vla) as DWARF expression evaluation
Jan> arbitrarily accesses inferior memory during DWARF_block* evaluation
Jan> for DW_AT_upper_bound and others.

I think the current gdb model is that a value is a snapshot of some
inferior state at a particular moment.

So, for VLA I would say that the bounds ought to be fixed at the time
the snapshot is taken.  I suppose this would mean introducing some copy
of the type.

Jan> OTOH there cannot be any `CORE_ADDR address' where the content
Jan> could be read from - for example for internal variables.

Yeah.  val_print doesn't usually read memory, though.  The address is
only occasionally used.

Tom> I started by looking briefly at replacing val_print.

Jan> Here you probably mean la_val_print->la_value_print unification:

Yes.

Tom> So, currently I am thinking I will go through my existing patch and have
Tom> it pass a value instead of lval_funcs.  Of course this means a lot of
Tom> redundant info, which is ugly.

Jan> Do you mean the unification proposed above or some other extension?

Right now what I've done is change val_print to:

int
val_print (struct type *type, const gdb_byte *valaddr, int embedded_offset,
	   CORE_ADDR address, struct ui_file *stream, int recurse,
	   const struct value *val,
	   const struct value_print_options *options,
	   const struct language_defn *language)

That is, I added the new 'val' argument.  This is only used for bit
validity testing.

Jan> Couldn't be just the `struct value' kept LAZY and creating struct
Jan> values for the dereferenced elements only with properly adjusted
Jan> object address?

One problem is that not all values are lazy.  Also, record_latest_value
specifically makes a value not lazy, but this could be fixed somehow.

Maybe this problem is not very important though.

Tom