Re: fortran multidimensional arrays and pointers

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

On Thu, 03 Mar 2011 18:23:58 +0100, Tom Tromey wrote:
> Jan> Some of them fix linux-nat which should be soon superseded by some
> Jan> form of remote stub (gdbserver or ugdb or etc.). Which makes them a
> Jan> bit useless after the switch but currently gdbserver is not a full
> Jan> replacement for linux-nat.
> 
> While I think this is a good future direction, I would not delay any
> patch while waiting for it to be finished.

It is not about waiting but there may be needed some effort before they get
merged and then (with gdbserver/ugdb/...) the code gets dropped anyway.


> Jan> Currently the dynamic types to static types are converted during
> Jan> check_typedef.  I believe check_typedef should be removed.
> 
> I guess I can see how it could be done: replace all TYPE_* macros with
> functions, and do the typedef indirection there.  Is that what you are
> thinking, or do you have some other idea?

check_typedef does multiple things, and more of them in the VLA branch.

One of them in FSF GDB is to set TYPE_LENGTH - this could be dynamic.

In other cases the code may want to access either the TYPE_CODE_TYPEDEF layer
or the dereferenced one (possibly resolved from TYPE_IS_OPAQUE) etc.
Sometimes the code wants to know if the boundary is dynamic sometimes it wants
to know the resolved number.

In general I agree but I would need to start patching the code first.

BTW also most of the `struct type *' pointers need to be changed
to `struct value *' as dynamic types resolving for VLA depends on the object
address (DW_AT_object_pointer).  There is a global variable for it in the VLA
branch but a global variable is wrong by design causing various problems
there.


> It seems to me that once you assign to a convenience variable, you are
> taking a snapshot of a particular instance of a VLA.  So, converting to
> a statically-bounded type would be the right thing to do here.

Yes, it is the right thing but completely needless.  There is a need for
discontiguous value->contents (such as for multidimensional array slices) and
there is a need for dynamic type parameters resolution (to simplify the code
by removing check_typedef).  In such case there is already enough
functionality one does not need to implement the conversion to static types.
It remains to be an inappropriate performance optimization.


> Jan> As with VLA even TYPE_HIGH_BOUND and other fields of main_type get
> Jan> runtime modified no longer makes any distinction the struct type
> Jan> vs. struct main_type.  Therefore they should be merged.
> 
> I am not so sure about this.  Type variants also save memory.

We can do some benchmarks if you mean it seriously but such memory saving has
no relevant size to ever consider it.


> Yeah.  I think we need to destroy val_print, and only have value_print
> -- but keep finding tricks to avoid it since it is so much work.  Once
> that is done, fully virtualizing struct value like this would not be so
> hard (famous last words), and would also let us address lazily read
> arrays at print time.

Yes, this cleanup has multiple benefits.


Thanks,
Jan