Hi,

On Mon, 18 Aug 2008 13:11:20 +0200, Joel Brobecker wrote:
> could you show us how Fortran arrays are described in DWARF?).

They use regular DWARF BLOCKs.  Just so far GDB supported these blocks only for
DW_AT_location while for Fortran they are used even for other attributes.
There is also new DW_OP_push_object_address, DW_AT_data_location,
DW_AT_associated and DW_AT_allocated.

 <2><6e>: Abbrev Number: 5 (DW_TAG_variable)
    <6f>   DW_AT_name        : (indirect string, offset: 0x63): varv    
    <73>   DW_AT_decl_file   : 1        
    <74>   DW_AT_decl_line   : 23       
    <75>   DW_AT_type        : <0x197>  
    <79>   DW_AT_location    : 3 byte block: 91 f0 7e   (DW_OP_fbreg: -144)
 <1><197>: Abbrev Number: 13 (DW_TAG_array_type)
    <198>   DW_AT_name        : (indirect string, offset: 0x107): array3_real(kind=4)   
    <19c>   DW_AT_ordering    : 1       (column major)
    <19d>   DW_AT_data_location: 2 byte block: 97 6     (DW_OP_push_object_address; DW_OP_deref)
    <1a0>   DW_AT_associated  : 4 byte block: 97 6 30 2e        (DW_OP_push_object_address; DW_OP_deref; DW_OP_lit0; DW_OP_ne)
    <1a5>   DW_AT_type        : <0x190> 
    <1a9>   DW_AT_sibling     : <0x1e4> 
 <2><1ad>: Abbrev Number: 14 (DW_TAG_subrange_type)
    <1ae>   DW_AT_lower_bound : 4 byte block: 97 23 20 6        (DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref)
    <1b3>   DW_AT_upper_bound : 4 byte block: 97 23 28 6        (DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref)
    <1b8>   DW_AT_stride      : 6 byte block: 97 23 18 6 34 1e  (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref;
 DW_OP_lit4; DW_OP_mul)


The patchset for HEAD as a single file is at:
	http://people.redhat.com/jkratoch/fortran-dynamic-arrays-HEAD-7.patch
(just FYI, not for a review as it is not split)

Attaching its first part - a very useless one on its own - its target is to
get a new storage space for two bits of info (TYPE_BOUND_IS_DWARF_BLOCK and
TYPE_BOUND_IS_DWARF_BLOCK).  I do not think it is the best way but it is
a minimal change without expanding the structure size.

One of such spare space there is `enum array_bound_type'  Except for
BOUND_CANNOT_BE_DETERMINED it is never set anywhere.  BOUND_BY_* are read only
in f-valprint.c.  In fact it could be probably used for the new bits
TYPE_BOUND_IS_DWARF_BLOCK and possibly TYPE_HIGH_BOUND_IS_COUNT but I would
rather like to later remove `enum array_bound_type' and its fields at all.

The patch modifies a lot of sources trying to follow the new style of
main_type bitfields instead of the former FLAGS variable.  I do not think
current main_type layout is right but the patch tries to follow the current
main_type style.  The original version of this patch (in current Fedora
Rawhide) used the FLAGS style access:
+#define TYPE_BOUND_IS_DWARF_BLOCK_MASK 1
+#define TYPE_BOUND_IS_DWARF_BLOCK_VAR(range_type, fieldno) \
+  TYPE_FIELD_STATIC_KIND (range_type, fieldno)
+#define TYPE_HIGH_BOUND_IS_COUNT_MASK 2
+#define TYPE_HIGH_BOUND_IS_COUNT_VAR(range_type) \
+  TYPE_FIELD_STATIC_KIND (range_type, 1)
+         TYPE_BOUND_IS_DWARF_BLOCK_VAR (range_type, 1)
+           |= TYPE_BOUND_IS_DWARF_BLOCK_MASK;
+  if ((TYPE_BOUND_IS_DWARF_BLOCK_VAR (range_type, 0)
+       & TYPE_BOUND_IS_DWARF_BLOCK_MASK) != 0

Also I do not understand why exist all the macros like this one at all:
#define TYPE_MAIN_TYPE(thistype) (thistype)->main_type
Why we cannot use it expanded?  This way it is always one (or more)
"tags"-jump (VIM ctrl-]) indirections while navigating the source files.

In the attached patch FIELD_STATIC_KIND was removed so the pairs like
-      FIELD_BITPOS (*f) = sh->value;
-      FIELD_STATIC_KIND (*f) = 0;
were replaced by
+      SET_FIELD_BITPOS (*f, sh->value);
but still just assignments to FIELD_BITPOS (without an assignment to
FIELD_STATIC_KIND) were left as they are.


Regards,
Jan