[PATCH] Re: DW_TAG_common_block children

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Aug 22, 2008 at 09:32:26AM +0100, George Helffrich wrote:
> 	I implemented this to be able to debug a rather large, 
> 	common-reliant Fortran program that I maintain, so my goal was getting 
> functionality.  The only way I could get it was by locating variables 
> relative to the common section's base address, leading to the use of 
> DW_TAG_member.

Why?  See attached patch below which should fix this (on top of
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01515.html ).
Note that the DW_AT_external flag is not listed as allowable attribute
for DW_TAG_common_block, but is for DW_TAG_variable, so it is moved
there as well.
The standard is there for a reason, we have multiple debug info
producers and multiple consumers and having a standard is the only way
they can reasonably interoperate.

> 	What really matters is if any change results in either loss of 
> functionality or erupts to a user-visible level.  (By that last 
> qualifier I mean, "Would a Fortran programmer have to refer to the 
> common variable in an unusual way using a debugger?"  And an example is 

If so, that would be a debugger bug.  The debugger has all the info
that it has Fortran COMMON variables when there are DW_TAG_variable
DIEs as children of DW_TAG_common_block.

> gdb's requirement that one use "print *var" to access a subprogram 
> parameter called "var" when Fortran 77 has no concept of an indirection 
> operator.)  Any reactions?

That is a bug on the GCC side, see my comment in
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01599.html on this (and I think
there is an open PR about it too).  GCC has DECL_BY_REFERENCE flag (though
just for PARM_DECLs/RESULT_DECLs ATM), which should be used in this case.
Except that I see it being broken even for C++, will need to fix it first.

	Jakub

Attachment: Z231b
Description: Text document