Re: fortran multidimensional arrays and pointers

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Thu, 24 Feb 2011 20:32:51 +0100, Mathew Yeates wrote:
> Okay. I'll bite. Why is this not yet merged in FSF GDB?

That is why archer-jankratochvil-vla is not merged.

I have other bugs and other branches much easier to merge and they are also
not merged.  While I understand it is better for all the sides to merge them
these branches currently live in Fedora (and Archer) and if anyone needs the
functionality it is Freely available so I find other serious bugs as a more
urgent problem myself.

Specifically from http://sourceware.org/gdb/wiki/ArcherBranchManagement:

archer-jankratochvil-ifunc: This should get merged soon / these days, I hope
                            still for gdb-7.3.
archer-jankratochvil-watchpoint3: Upon Pedro's reply
  http://sourceware.org/ml/gdb-patches/2010-12/msg00348.html
  http://sourceware.org/ml/gdb-patches/2011-01/msg00561.html
  I find it now waiting on some merge of linux-nat and gdbserver code which
  seems to be continually being worked on by Yao Qi.  As I have other work to
  do I find it OK to just delay the merge after it.

There are other patches which are very small compared to VLA and which I would
also like to also merge, which suggest me they could be merged before VLA.
Some of them fix linux-nat which should be soon superseded by some form of
remote stub (gdbserver or ugdb or etc.). Which makes them a bit useless after
the switch but currently gdbserver is not a full replacement for linux-nat. It
is all related to the Yao's merges mentioned above.
	[patch 3/4]#3 linux-nat: Do not respawn signals
	http://sourceware.org/ml/gdb-patches/2010-09/msg00360.html
	[patch] Fix syscall restarts for amd64->i386 biarch
	http://sourceware.org/ml/gdb-patches/2009-11/msg00592.html
	[patch] Fix hang on the thread leader exit
	http://sourceware.org/ml/gdb-patches/2007-07/msg00136.html
	SIGSTOP which need first an upstream kernel support discussed now on lkml.
	various other

archer-jankratochvil-vla:
The patches exist since Mar 2008, currently I believe most of the code should
be rewritten rather than merged.  There was an unsuccessful attempt to merge
it early and I later gave up on its merge and developed it rather maintainable
standalone.  Currently it became no longer meaningfully extensible as such
non-integrated add-on patches.

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

With check_typedef the GDB code is known to sometimes forget to call it.
Moreover with dynamic types sometimes one wants to call it only for a single
"type layer" (and no longer for its TYPE_TARGET_TYPE), in other cases one
wants to call it for the type and all its subtypes.

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

As with VLA even TYPE_HIGH_BOUND and other fields of main_type get runtime
modified no longer makes any distinction the struct type vs. struct main_type.
Therefore they should be merged.  struct type was separate so that it could be
modified as there was a limited number of its variants and so it does not
matter they can never be freed.  With proper life cycle managemement there can
be single struct type/main_type.

struct value needs to be simplified.  At least for lval_memory the fields like
OFFSET, ENCLOSING_TYPE, EMBEDDED_OFFSET and POINTED_TO_OFFSET cannot be used
as the memory accessed by the type is no longer contiguous anyway (value
address is a pointer to the descriptor where are contained the type's
boundaries and also pointer to the real data).

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

I wrote it just off the top of my head now without any patches but sure some
comments are welcome.


Thanks,
Jan