Re: RFC: partially fix empty DW_OP_piece

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 01 Jun 2010 18:41:51 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Tom> The other way is to simply remove val_print entirely and make all of
> Tom> printing work using values.  I think this is the route I would prefer.
> 
> Jan> That could hopefully solve the problem of missing type-associated object
> Jan> address for DW_OP_push_object_address for the VLA (variable length arrays)
> Jan> patch.
> 
> I am curious to know what you need here.

I do not understand the prototype:
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_print_options *options,
           const struct language_defn *language)
struct language_defn:
    int (*la_val_print) (struct type *type,
                         const gdb_byte *contents,
                         int embedded_offset, CORE_ADDR address,
                         struct ui_file *stream, int recurse,
                         const struct value_print_options *options);

There cannot be any `const gdb_byte *contents' for types with DWARF_block* as
their attribute (=TYPE_DYNAMIC from archer-jankratochvil-vla) as DWARF
expression evaluation arbitrarily accesses inferior memory during DWARF_block*
evaluation for DW_AT_upper_bound and others.  VLA patchset also deals with two
ADDRESSes - object address (needed for DWARF_block*'s
DW_OP_push_object_address evaluation) and data address (DW_AT_data_location,
neede for the content printing - but data address can be derived from the
object address; apparently data address cannot be converted to object
address).

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

Therefore we need to use both accesses depending on the object class.
I believe `struct value' stricly being LAZY can be used for inferior objects
(and non-LAZY `struct value' for internal variables).  Only in some final
moment (of arrays dereferencing etc.) the inferior LAZY vary can be fetched.


> I started by looking briefly at replacing val_print.

Here you probably mean la_val_print->la_value_print unification:
struct language_defn:
    int (*la_val_print) (struct type *type,
                         const gdb_byte *contents,
                         int embedded_offset, CORE_ADDR address,
                         struct ui_file *stream, int recurse,
                         const struct value_print_options *options);

by keeping only existing:
struct language_defn:
    int (*la_value_print) (struct value *, struct ui_file *,
                           const struct value_print_options *);


> This looks pretty big, though.  So I looked into other solutions.

I believe it will need to be done anyway for the sane integration of the VLA
patchset.


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

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


> There are barriers to removing val_print.  I think the biggest one,
> conceptually, is that recursion in val_print means making new values,

Yes, I think it is required for the case of Pascal arrays of strings - each
element of Pascal array is a VLA array (=string); gdb.pascal/arrays.exp by
Joost van der Sluis in archer-jankratochvil-vla.  Each element is a full-blown
dynamic objects without much possibilities of a simplication.


> which means copying the value contents.  This can be expensive.  (Of
> course there are solutions to that, reference counting the value
> contents comes to mind.)

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


Thanks,
Jan