[Bug debug/8354] Incorrect DWARF-2/3 emitted for const + array

["gary at intrepid dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #11 from gary at intrepid dot com  2006-12-30 06:34 -------
I looked into fixing GCC's DWARF 2
generation for types that are qualified (for example, "const"
and "volatile", and in the case of UPC, "shared", "strict",
and "relaxed") in order to ensure that GDB has an accurate
understanding of when a particular object's type is
qualified:
http://sourceware.org/ml/gdb/2006-11/msg00185.html
http://sourceware.org/ml/gdb/2006-12/msg00133.html
http://sourceware.org/ml/gdb/2006-12/msg00177.html

In the latter e-mail reply, copied below, I sketched
out three possible ways to fix the DWARF 2 information
that GCC presently generates for qualified types.

It would be great if someone familiar with the GCC
front-end reviews my analysis, and either corrects it,
or improves upon the suggested approaches.

Additionally, I'm a bit unsure on what
the "correct" DWARF 2 information should look like in
all cases.  For example should the members/fields of
a struct/union that is C-V qualified also be individually
qualified?  One commercial compiler that I tried did not
do this.

Alternatively, would all the possible DWARF 2
type qualifier representation issues best be handled
within GDB?  This would move the problem from GCC back
to GDB, and at the same time improve upon
inter-operability.

--- copy of http://sourceware.org/ml/gdb/2006-12/msg00177.html ---
Jim Blandy wrote: 
>
> "Gary Funck" <gary@intrepid.com> writes:
> > The main difficulty is that GCC doesn't create new qualified
> > types for declarations.  Rather, it sets TREE_READONLY()
> > and TREE_THIS_VOLATILE() in the DECL node for declarations
> > such as:
> >
> >    volatile int A[10];
> 
> Ugh.  That's a shame.  Can't dwarf2out.c fix things up as it builds
> the tree of struct die_structs from the GCC 'tree' type tree?

In theory, it should be possible.  I worked on this a bit, but I think
to do it right, this fix will require contribution/direction from someone
more conversant in the GCC front-end, and more knowledgeable about how
the other language front-ends use both the DWARF 2 generation
routines, and the extent to which they depend upon the type information
remaining in its current form.

Three approaches to fixing the front end to create
appropriate DWARF 2 information come to mind:

(1) Change the GCC front-end, so that when it creates
type information and associates the type information
with a declaration that it fully qualifies the type definition,
in a way that preserves language semantics, yet also ensures
that the correct DWARF 2 information is generated for qualified
types.

(2) Create the fully qualified type definition in dwarf2out.c
(probably in routines that handle DECL items such as
gen_formal_parameter_die(), gen_variable_die() and gen_field_die()).
There are two likely sub-approaches: (i) keep this fully
qualified type definition on the side, parallel to the existing
type definition structure, or (ii) smash the new fully qualified
type into the DECL node's TREE_TYPE() value.  Keeping a
parallel definition may be difficult because various parts
of dwarfout.c may need to refer back to the DECL node's type
value, and all places that do this will have to be found and fixed.
Cross-type references and typedef's create another set of problems.
Rewriting the declaration's type value is the most straightforward,
but runs the risk of violating various assumptions made by the
language front-ends, and will require a rather elaborate "deep copy"
mechanism to make sure the fix up is done correctly.

(3) Run a final pass over the internal DWARF tree built within
dwarfout.c to fix up the type qualifiers, basically propagating
the const_ and volatile_ qualifiers down to lower levels as
required.  This is probably doable, but will slow down DWARF
generation for all compilations, even if most compilations
seldom use "const" and "volatile" (and other qualifiers, such
as UPC's "shared", "strict", and "relaxed").  In this case, it
seems that dwarf2out.c is fixing representation
issues that more correctly should be solved in the front-end.

Given the tradeoffs, choice (1) above, where the type description
is fully qualified at the time the type is bound to the DECL item,
seems more correct, but may impact the correct operation of
the various language front-ends and therefore will require more
care and more study.  Choice (2) is perhaps a bad compromise,
and choice (3) is likely workable, but kludgy.


-- 

gary at intrepid dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gary at intrepid dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8354