Re: [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays]

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

On Mon, 08 Sep 2008 17:30:47 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> The patch modifies a lot of sources trying to follow the new
> Jan> style of main_type bitfields instead of the former FLAGS
> Jan> variable.  I do not think current main_type layout is right but
> Jan> the patch tries to follow the current main_type style.
> 
> Do you mean the main_type layout after this patch, or before this patch?
> If before -- could you be more specific?

Both before and it gets a bit worse after.  There should be a union with
fields for each very specific TYPE_CODE_*.

TYPE_CODE_ARRAY is terrible - it has always exactly NFIELDS==1 with
fields[0].type->main_type pointing to TYPE_CODE_RANGE having exactly NFIELDS==2
(for the lower and upper bound).  If we try so much to save some main_type
memory:
* fields[0].loc is not used.
* nfields everywhere is not used.
* main_type for TYPE_CODE_RANGE is not used as DW_TAG_subrange_type's
  DW_AT_type is stored into TYPE_CODE_RANGE's TYPE_TARGET_TYPE.
We should have just one TYPE_CODE_ARRAY main_type pointing to the element-type
(DW_TAG_array_type's DW_AT_type - which is right as its target_type) also also
one simple pointer to the index type (DW_TAG_subrange_type's DW_AT_type
- currently stored in TYPE_CODE_RANGE's target_type).

target_type, vptr_fieldno, vptr_basetype and some cases of fields[] is used
only for some types and for other types they are left unused.  These fields
should be moved to the type_specific union.

fields[] with nfields should be moved into the type_specific union for
specific types TYPE_CODE_FUNC, TYPE_CODE_STRUCT and some others.

Simple union would make it all more clear, optimal for the memory size and
even allocatable with variable length.

Some better encapsulation would benefit the dynamic bounds I hacked into the
current code.  There should be a virtual method with MAIN_TYPE containing
generic abstract class type.
class debuginfo_value                  { virtual LONGEST get() = 0; };
class dwarf2_integer : debuginfo_value { virtual LONGEST get() { ... }; };
class dwarf2_block   : debuginfo_value { virtual LONGEST get() { ... }; };
class main_type { ...; debuginfo_value upper_bound_value; ... };
LONGEST is not right as we need to return also unbound/undefined results.
Just C++ requires pointer (or reference) as upper_bound_value which is
inefficient so a C implementation (knowing the maximum size of all the
inherited classes) should be better here, right?

If the memory of main_type is so critical (I doubt so but i did not measure
it) in my Fortran/dynamic-bounds patch main_type had to get three new pointers
almost always being NULL.  These three pointers may need to be set for any
type so the base struct main_type has to be extended for them.
We could instead use the Amiga "tags" data format with variable block size
allocation (but sure slow access time which should not matter here):
struct main_type { ...; void *tags[1]; };
memcpy (main_type->tags,
	{ DW_AT_allocated, 0x601010,
	  DW_AT_associated, 0x610348,
	  NULL /* terminator */
	});


Regards,
Jan