[00/11] Fortran dynamic arrays support

[00/11] Fortran dynamic arrays support

[Jan Kratochvil]

Hi,

currently GDB cannot display allocated or associated (dynamic) Fortran arrays.
Support for the DWARF annotation of these is still not commited in GCC SVN.
GCC Bug:
	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
Latest GCC 4.3 patch:
	http://people.redhat.com/jkratoch/rh364001/gcc22244-Z40d-jakub.patch
Prebuilt Fortran testcase:
	http://people.redhat.com/jkratoch/rh364001/testcase-a5-jakub.tar.gz
Jakub's mail (old):
	http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00612.html

This patchset should also enable proper handling of C VLAs (Variable Length
Arrays) but GCC-4.x does not emit any DWARF and the GCC-3.4 DWARF was IMO wrong
for them.

These GDB features are missing and get implemented by the patchset:
* Dynamic array bounds.
* DW_AT_*stride.
* DW_AT_data_location.
* DW_FORM_block* for DW_AT_lower_bound, DW_AT_upper_bound, DW_AT_*stride.

Most of the support was intentionally limited only for the Fortran arrays where
it is currently only produced by GCC.

Patchset has incremental dependencies.  All stages are buildable but only the
full patchset has been regression tested by the testsuite.

Current output is:
	(gdb) ptype varx
	type = real*4 (0:-1,0:-1,0:-1)
	(gdb) p varx
	$1 = ()
Patched output is:
	(gdb) ptype varx
	type = real*4 (6,5:15,17:28)
	(gdb) p varx
	$1 = (( ( 7, 6, 6, 6, 6, 6) ( 6, 6, 6, 6, 6, 6) ( 6, [cut ...]

There is a design problem that GDB deals with the TYPE already without any
relation to the original variable.  I tried to patch there a general
TYPE->VARIABLE binding first but it is too intrusive for GDB as it makes the
same abstract TYPE and VARIABLE-bound TYPE two different objects.  Current
patchset provides another function parameter in the codepaths requiring it.

Another design problem is that TYPE_LENGTH (and other macros) defined as
`type->length' need to behave dynamically now (calculate DWARF expressions) but
the same macro is currently used everywhere both as the setter (lval) and the
getter.  Currently the getter call is replaced on (few) places where it was
required for the Fortran arrays.

I can expand there some of the compatibility wrapping functions if it gets
otherwise accepted.

This GCC Fortran <-> GDB patches were not tested against any 3rd part DWARF
producers/consumers (which exist?).


Regards,
Jan

Re: [00/11] Fortran dynamic arrays support

[Jim Blandy]

Hi, Jan.  I would be a natural reviewer for this, but I'll be on
vacation next week (it's the U.S. Thanksgiving holiday), so I, at
least, won't be able to review this promptly.

Jan Kratochvil <jan.kratochvil at redhat.com> writes:
> currently GDB cannot display allocated or associated (dynamic) Fortran arrays.
> Support for the DWARF annotation of these is still not commited in GCC SVN.
> GCC Bug:
> 	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
> Latest GCC 4.3 patch:
> 	http://people.redhat.com/jkratoch/rh364001/gcc22244-Z40d-jakub.patch
> Prebuilt Fortran testcase:
> 	http://people.redhat.com/jkratoch/rh364001/testcase-a5-jakub.tar.gz
> Jakub's mail (old):
> 	http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00612.html
>
> This patchset should also enable proper handling of C VLAs (Variable Length
> Arrays) but GCC-4.x does not emit any DWARF and the GCC-3.4 DWARF was IMO wrong
> for them.
>
> These GDB features are missing and get implemented by the patchset:
> * Dynamic array bounds.
> * DW_AT_*stride.
> * DW_AT_data_location.
> * DW_FORM_block* for DW_AT_lower_bound, DW_AT_upper_bound, DW_AT_*stride.
>
> Most of the support was intentionally limited only for the Fortran arrays where
> it is currently only produced by GCC.
>
> Patchset has incremental dependencies.  All stages are buildable but only the
> full patchset has been regression tested by the testsuite.
>
> Current output is:
> 	(gdb) ptype varx
> 	type = real*4 (0:-1,0:-1,0:-1)
> 	(gdb) p varx
> 	$1 = ()
> Patched output is:
> 	(gdb) ptype varx
> 	type = real*4 (6,5:15,17:28)
> 	(gdb) p varx
> 	$1 = (( ( 7, 6, 6, 6, 6, 6) ( 6, 6, 6, 6, 6, 6) ( 6, [cut ...]
>
> There is a design problem that GDB deals with the TYPE already without any
> relation to the original variable.  I tried to patch there a general
> TYPE->VARIABLE binding first but it is too intrusive for GDB as it makes the
> same abstract TYPE and VARIABLE-bound TYPE two different objects.  Current
> patchset provides another function parameter in the codepaths requiring it.
>
> Another design problem is that TYPE_LENGTH (and other macros) defined as
> `type->length' need to behave dynamically now (calculate DWARF expressions) but
> the same macro is currently used everywhere both as the setter (lval) and the
> getter.  Currently the getter call is replaced on (few) places where it was
> required for the Fortran arrays.
>
> I can expand there some of the compatibility wrapping functions if it gets
> otherwise accepted.
>
> This GCC Fortran <-> GDB patches were not tested against any 3rd part DWARF
> producers/consumers (which exist?).
>
>
> Regards,
> Jan

Re: [00/11] Fortran dynamic arrays support

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 
> This GCC Fortran <-> GDB patches were not tested against any 3rd part DWARF
> producers/consumers (which exist?).
> 
> 
> Regards,
> Jan

Jan

Just FYI, your patch doesn't seem to work with binaries compiled on XLF:

(gdb) ptype varx
warning: Object count -17 < 0
type = real*4 (*,5:*,17:*)
(gdb) p varx
warning: Object count -17 < 0
warning: Object count -17 < 0
$5 = (<assumed size array> Cannot resolve DW_OP_push_object_address for
a missing object
<error reading variable>

Regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHPdltqvq7Aov/qQARAt5eAJ0STkqxN8GuNSY2Itp3bEr+EirmpgCeIQrm
tfomGB5QeBz/tA7wdAxiCig=
=7G04
-----END PGP SIGNATURE-----

Re: [00/11] Fortran dynamic arrays support

[Jan Kratochvil]

On Fri, 16 Nov 2007 18:54:53 +0100, Carlos Eduardo Seo wrote:
...
> Just FYI, your patch doesn't seem to work with binaries compiled on XLF:
> 
> (gdb) ptype varx
> warning: Object count -17 < 0
> type = real*4 (*,5:*,17:*)

I see from your file XLF is using DW_AT_count instead of DW_AT_upper_bound.
DW_AT_count is so far unsupported by GDB.

I will post another patch (#12) on top of the series.


Thanks,
Jan

Re: [00/11] Fortran dynamic arrays support

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jan Kratochvil wrote:
>
> I see from your file XLF is using DW_AT_count instead of DW_AT_upper_bound.
> DW_AT_count is so far unsupported by GDB.
>
> I will post another patch (#12) on top of the series.
Great! If you need anything else, please feel free to ask.

Regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQaB2qvq7Aov/qQARAunFAJ4010L7HDfA3zQ8fOQks/HwcWGZXwCdESAb
ZRLSftdZE7Fo60PwTdZE7Vc=
=LeAb
-----END PGP SIGNATURE-----

[patch] XLF Fortran: Remove an inappropriate complaint [Re: XLF Fortran arrays test]

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Fri, 23 Nov 2007 18:05:48 +0100, Carlos Eduardo Seo wrote:
...
> The only strange behavior is that when I set a breakpoint, I get this
> message:
> 
> During symbol reading, DW_AT_type missing from DW_TAG_subrange_type.

This code was there already before my changes.  And the XLF output really
misses DW_AT_type for DW_TAG_subrange_type.  But it should be correct:
	http://dwarf.freestandards.org/Dwarf3.pdf
	5.12 Subrange Type Entries
	The subrange entry may have a DW_AT_type attribute to describe the type
	of object, called the basis type, of whose values this subrange is
	a subset.

"may have" should not produce a `complaint' category message as it is not
a standard violation.

Providing a patch but I do not know much more about it.


Regards,
Jan

[-- Attachment #2: gdb-subrange-no-type-ok.patch --]
[-- Type: text/plain, Size: 611 bytes --]

2007-11-23  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* dwarf2read.c (read_subrange_type): Remove the missing DW_AT_type
	complaint.
	
--- ./gdb/dwarf2read.c	25 Oct 2007 20:54:27 -0000	1.236
+++ ./gdb/dwarf2read.c	23 Nov 2007 17:17:44 -0000
@@ -4933,8 +4933,6 @@ read_subrange_type (struct die_info *die
   base_type = die_type (die, cu);
   if (TYPE_CODE (base_type) == TYPE_CODE_VOID)
     {
-      complaint (&symfile_complaints,
-                _("DW_AT_type missing from DW_TAG_subrange_type"));
       base_type
 	= dwarf_base_type (DW_ATE_signed,
 			   gdbarch_addr_bit (current_gdbarch) / 8, cu);

Re: [patch] XLF Fortran: Remove an inappropriate complaint [Re: XLF Fortran arrays test]

[Daniel Jacobowitz]

On Fri, Nov 23, 2007 at 06:21:04PM +0100, Jan Kratochvil wrote:
> On Fri, 23 Nov 2007 18:05:48 +0100, Carlos Eduardo Seo wrote:
> ...
> > The only strange behavior is that when I set a breakpoint, I get this
> > message:
> > 
> > During symbol reading, DW_AT_type missing from DW_TAG_subrange_type.
> 
> This code was there already before my changes.  And the XLF output really
> misses DW_AT_type for DW_TAG_subrange_type.  But it should be correct:
> 	http://dwarf.freestandards.org/Dwarf3.pdf
> 	5.12 Subrange Type Entries
> 	The subrange entry may have a DW_AT_type attribute to describe the type
> 	of object, called the basis type, of whose values this subrange is
> 	a subset.
> 
> "may have" should not produce a `complaint' category message as it is not
> a standard violation.
> 
> Providing a patch but I do not know much more about it.

Here's the rest of what the standard has to say:

==
If the subrange entry has no type attribute describing the basis type,
the basis type is assumed to be the same as the object described by
the lower bound attribute (if it references an object). If there is no
lower bound attribute, or that attribute does not reference an object,
the basis type is the type of the upper bound or count attribute (if
either of them references an object). If there is no upper bound or
count attribute, or neither references an object, the type is assumed
to be the same type, in the source language of the compilation unit
containing the subrange entry, as a signed integer with the same size
as an address on the target machine.
==

It looks to me like (before your other patches?) we do not support
the bounds or count referring to objects.  The code below the
complaint is creating a signed integer type the size of an address.
So your patch is OK.  Thanks.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] XLF Fortran: Remove an inappropriate complaint [Re: XLF Fortran arrays test]

[Jan Kratochvil]

On Sun, 25 Nov 2007 15:55:55 +0100, Daniel Jacobowitz wrote:
> On Fri, Nov 23, 2007 at 06:21:04PM +0100, Jan Kratochvil wrote:
> > On Fri, 23 Nov 2007 18:05:48 +0100, Carlos Eduardo Seo wrote:
> > ...
> > > During symbol reading, DW_AT_type missing from DW_TAG_subrange_type.
> > 
> > This code was there already before my changes.  And the XLF output really
> > misses DW_AT_type for DW_TAG_subrange_type.  But it should be correct:
> > 	http://dwarf.freestandards.org/Dwarf3.pdf
> > 	5.12 Subrange Type Entries
> > 	The subrange entry may have a DW_AT_type attribute to describe the type
> > 	of object, called the basis type, of whose values this subrange is
> > 	a subset.
> > 
> > "may have" should not produce a `complaint' category message as it is not
> > a standard violation.
> 
> Here's the rest of what the standard has to say:
> 
> ==
> If the subrange entry has no type attribute describing the basis type,
> the basis type is assumed to be the same as the object described by
> the lower bound attribute (if it references an object). If there is no
> lower bound attribute, or that attribute does not reference an object,
> the basis type is the type of the upper bound or count attribute (if
> either of them references an object). If there is no upper bound or
> count attribute, or neither references an object, the type is assumed
> to be the same type, in the source language of the compilation unit
> containing the subrange entry, as a signed integer with the same size
> as an address on the target machine.
> ==
> 
> It looks to me like (before your other patches?) we do not support
> the bounds or count referring to objects.

Before my patches
	http://sources.redhat.com/ml/gdb-patches/2007-11/msg00438.html
the code supported for the bounds
	DW_FORM_sdata, DW_FORM_udata, DW_FORM_data{1,2,4,8}
and after my patches it supports the bounds/count
	DW_FORM_block{,1,2,4}
To reference `object' it would have to support
	DW_FORM_reF*
but this form is still not supported.


> The code below the
> complaint is creating a signed integer type the size of an address.
> So your patch is OK.  Thanks.

I see now my point is wrong.  The code still violates (notwithstanding of any
of my Fortran patches) the DWARF standard as it ignores
DW_AT_lower_bound/DW_AT_upper_bound/DW_AT_count with DW_FORM_ref* which may
specify the intended type through another DIE (as can be seen in DWARF3 D.2.2).



Sorry,
Jan

Re: [patch] XLF Fortran: Remove an inappropriate complaint [Re: XLF Fortran arrays test]

[Daniel Jacobowitz]

On Sun, Nov 25, 2007 at 11:10:37PM +0100, Jan Kratochvil wrote:
> > The code below the
> > complaint is creating a signed integer type the size of an address.
> > So your patch is OK.  Thanks.
> 
> I see now my point is wrong.  The code still violates (notwithstanding of any
> of my Fortran patches) the DWARF standard as it ignores
> DW_AT_lower_bound/DW_AT_upper_bound/DW_AT_count with DW_FORM_ref* which may
> specify the intended type through another DIE (as can be seen in DWARF3 D.2.2).

I'm confused.  What's wrong?

The patch I was replying to removed the complaint call.  That seems
fine, since it isn't related to DW_FORM_ref* support.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] XLF Fortran: Remove an inappropriate complaint

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

On Sun, 25 Nov 2007 23:13:57 +0100, Daniel Jacobowitz wrote:
...
> I'm confused.  What's wrong?
> 
> The patch I was replying to removed the complaint call.  That seems
> fine, since it isn't related to DW_FORM_ref* support.

The attached file (a binary patched one GCC output) should have for
DW_TAG_array_type <7a>:

According to the DWARF3 spec: index type `short int'.

Current CVS HEAD GDB complains and assigns: index type `long int' (64-bit int).

Therefore GDB violates the DWARF3 spec and the complaint there is right as it
warns the user GDB has violated the DWARF3 spec while parsing the ELF file.



Regards,
Jan


Contents of the .debug_abbrev section:

  Number TAG
   2      DW_TAG_variable    [no children]
    DW_AT_name         DW_FORM_string
    DW_AT_decl_file    DW_FORM_data1
    DW_AT_decl_line    DW_FORM_data1
    DW_AT_type         DW_FORM_ref4
    DW_AT_external     DW_FORM_flag
    DW_AT_location     DW_FORM_block1
   3      DW_TAG_base_type    [no children]
    DW_AT_name         DW_FORM_string
    DW_AT_byte_size    DW_FORM_data1
    DW_AT_encoding     DW_FORM_data1
   4      DW_TAG_array_type    [has children]
    DW_AT_sibling      DW_FORM_ref4
    DW_AT_type         DW_FORM_ref4
   5      DW_TAG_subrange_type    [no children]
    DW_AT_upper_bound  DW_FORM_ref1
    DW_AT_visibility   DW_FORM_data4

The section .debug_info contains:

  Compilation Unit @ offset 0x0:
   Pointer Size:  8
 <1><55>: Abbrev Number: 2 (DW_TAG_variable)
  <56>     DW_AT_name        : bound	
  <5c>     DW_AT_decl_file   : 1	
  <5d>     DW_AT_decl_line   : 1	
  <5e>     DW_AT_type        : <6d>	
  <62>     DW_AT_external    : 1	
  <63>     DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0 	(DW_OP_addr: 0)
 <1><6d>: Abbrev Number: 3 (DW_TAG_base_type)
  <6e>     DW_AT_name        : short int	
  <78>     DW_AT_byte_size   : 2	
  <79>     DW_AT_encoding    : 5	(signed)
 <1><7a>: Abbrev Number: 4 (DW_TAG_array_type)
  <7f>     DW_AT_type        : <9f>	
 <2><83>: Abbrev Number: 5 (DW_TAG_subrange_type)
  <84>     DW_AT_upper_bound : <55>	
  <85>     DW_AT_visibility  : 0x2	(exported)
 <1><9f>: Abbrev Number: 3 (DW_TAG_base_type)
  <a0>     DW_AT_name        : char	
  <a5>     DW_AT_byte_size   : 1	
  <a6>     DW_AT_encoding    : 6	(signed char)

[-- Attachment #2: type-var.o.gz --]
[-- Type: application/x-gzip, Size: 652 bytes --]

Re: [patch] XLF Fortran: Remove an inappropriate complaint

[Daniel Jacobowitz]

On Mon, Nov 26, 2007 at 08:20:41AM +0100, Jan Kratochvil wrote:
> Therefore GDB violates the DWARF3 spec and the complaint there is right as it
> warns the user GDB has violated the DWARF3 spec while parsing the ELF file.

OK, I see now.  But it will complain about the type anyway:

      complaint (&symfile_complaints, _("Attribute value is not a constant (%s)"),
                 dwarf_form_name (attr->form));

I have no preference - the patch is OK, leaving the complaint is also
OK with me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] XLF Fortran: Remove an inappropriate complaint

[Jan Kratochvil]

On Mon, 26 Nov 2007 14:26:34 +0100, Daniel Jacobowitz wrote:
> On Mon, Nov 26, 2007 at 08:20:41AM +0100, Jan Kratochvil wrote:
> > Therefore GDB violates the DWARF3 spec and the complaint there is right as it
> > warns the user GDB has violated the DWARF3 spec while parsing the ELF file.
> 
> OK, I see now.  But it will complain about the type anyway:
> 
>       complaint (&symfile_complaints, _("Attribute value is not a constant (%s)"),
>                  dwarf_form_name (attr->form));
> 
> I have no preference - the patch is OK, leaving the complaint is also
> OK with me.

I believe no one is ever going to fix this bug which does not bite.  Still the
complaint is IMO correct there as it is a bug so not going to apply the patch.
Thanks for notifying that my initial decision was too quick.


Regards,
Jan