Re: fortran multidimensional arrays and pointers

[Tom Tromey <tromey at redhat dot com>]

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.

Jan> archer-jankratochvil-vla:
Jan> The patches exist since Mar 2008, currently I believe most of the
Jan> code should be rewritten rather than merged.

Ouch.

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?

Jan> For storing dynamic variables into convenience variables $foo there
Jan> should just be stored all the parts of memory needed to evaluate
Jan> the dynamic bounds into `struct value' (that is to support
Jan> discontiguous value->contents).  In early VLA patchset versions the
Jan> macros accessing struct main_type evaluated the values dynamically.

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.

Jan> There were patches for type reference counting / garbage collecting
Jan> - those were needed for the check_typedef dynamic->static variant.
Jan> The types life cycle management should not be needed for VLAs with
Jan> dynamic check_typedef.

FWIW this work still seems relevant; you can still leak types via
Python.  It isn't urgent since this only happens in relatively weird
scenarios.

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.

Jan> There should be provided some sharing of value->contents to make
Jan> the code for dereferencing each dimension simple and bug-free.
Jan> Fetching of the discontiguous content can be made more by virtual
Jan> methods with in-GDB cache, where record_latest_value will fetch
Jan> everything.

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.

Tom