Re: Calculating array length

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

On Sun, 21 Jun 2009 14:22:48 +0200, Joost van der Sluis wrote:
> It only works partly. The length of the strings are ok. But they are not
> displayed correctly. That's because at the object_address points at the
> address where another address is stored, which points at the actual
> string. With your patch this second address is printed as the output.
> 
> So not only the type has to be evaluated again for each element, also
> the data-location.

This was an intention in my testcase+patch but sure there will be various bugs
- I also did not include it to the repository due to them.

> >   struct string_t
> >     {
>     <8e>   DW_AT_data_location: 2 byte block: 97 6      (DW_OP_push_object_address; DW_OP_deref)
> >       const char *string;
                ^^^^^^
> >       unsigned long length;
> >     }



> But this means that the object address of a type should be set. Where do
> we do that? And is it true that a 'struct type *' is only used for one
> variable at a time? How do we enforce that?

`struct type *' can used many times for various objects.  But the code should
be changed to use `struct value *' - and that one should be created for each
variable (array element) separately.


> I was working on a patch that removes the dynamic stuff from the 'stuct
> type *' into the 'struct value *'.

Yes, I would like it such way.


> That works, but the main problem with that is that the *_val_print functions
> do not have a 'struct value *' as parameter, so they can not access it. Or
> they should construct a new 'struct value' from the type and the address. 

Yes, something like that.


> So maybe we should adapt value_fetch_lazy so that it does not only sets
> val_address, but also the  dynamic fields in the type.

I think that even before value_fetch_lazy the GDB code needs to know various
dynamic parameters like the element stride, probably the dimensions etc. even
before value_fetch_lazy would be made.

Imagine accessing element [1,1,1,1] of a terribly big array.  GDB should not
call value_fetch_lazy for the whole array, it should work with the
dimensions/addresses only and apply value_fetch_lazy only on the single final
element (knowing its final address).

I do not think there should be something like check_value (making the dynamic
values static) instead of current check_typedef.  There has to be some sanity
check one does not access the parameter (such as the stride) before it gets
calculated from its dynamic representation.  And such sanity check can just
on-demand evaluate it on the first access instead.  It is true `value' should
not change after its parameters have been accessed on some final object
address - for subelements of an array a new `value' should be always created
(instead of modifying/reusing the old `value').



Thanks,
Jan