https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2019-08-22
CC| |tromey at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we're now handling the definition via
static void
gen_variable_die (tree decl, tree origin, dw_die_ref context_die)
{
...
else if (decl_will_get_specification_p (old_die, decl, declaration))
{
/* This is a definition of a C++ class level static. */
add_AT_specification (var_die, old_die);
...
earlier in gen_decl_die we already do
26451 gen_type_die (TREE_TYPE (decl_or_origin), context_die);
unconditionally, creating a dangling type DIE, so it seems reasonable
to attach that if it doesn't match what is already there in the specification.
Now the question is how often this triggers.
Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c (revision 274816)
+++ gcc/dwarf2out.c (working copy)
@@ -23928,6 +23928,10 @@ gen_variable_die (tree decl, tree origin
if (old_die->die_tag == DW_TAG_member)
add_linkage_name (var_die, decl);
}
+ dw_die_ref type_die = lookup_type_die (TREE_TYPE (decl));
+ dw_attr_node *a = get_AT (var_die, DW_AT_type);
+ if (type_die && (!a || AT_ref (a) != type_die))
+ add_AT_die_ref (var_die, DW_AT_type, type_die);
}
else
add_name_and_src_coords_attributes (var_die, decl, no_linkage_name);
The alternative is to try fixing this in the FE by delaying finalization
of the declaration. The question is whether that declared variable can
end up being referenced in things we throw at dwarf2out and thus whether
a DIE for it might end up created anyways. Like
extern char *zzz[];
const char **p = zzz;
char *zzz[] = {
"abc",
"cde"
};
but we're not creating a DIE ref for the constant initializer (yet).
Anyhow, with the patch we create
<1><1d>: Abbrev Number: 2 (DW_TAG_array_type)
<1e> DW_AT_type : <0x28>
<22> DW_AT_sibling : <0x28>
<2><26>: Abbrev Number: 3 (DW_TAG_subrange_type)
<2><27>: Abbrev Number: 0
...
<1><35>: Abbrev Number: 6 (DW_TAG_variable)
<36> DW_AT_name : zzz
<3a> DW_AT_decl_file : 1
<3b> DW_AT_decl_line : 1
<3c> DW_AT_decl_column : 14
<3d> DW_AT_type : <0x1d>
<41> DW_AT_external : 1
<41> DW_AT_declaration : 1
<1><41>: Abbrev Number: 2 (DW_TAG_array_type)
<42> DW_AT_type : <0x28>
<46> DW_AT_sibling : <0x51>
<2><4a>: Abbrev Number: 7 (DW_TAG_subrange_type)
<4b> DW_AT_type : <0x51>
<4f> DW_AT_upper_bound : 1
...
<1><58>: Abbrev Number: 8 (DW_TAG_variable)
<59> DW_AT_specification: <0x35>
<5d> DW_AT_decl_line : 2
<5e> DW_AT_decl_column : 7
<5f> DW_AT_type : <0x41>
<63> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
but I guess it isn't of much additional value to the debug info consumer
to have both the declaration and the specification...? Still for C++
class level statics it was deemed to be useful and this C variant really
looks similar enough.
Btw, the C++ FE behaves exactly the same as the C FE on the testcase in this
bug.
gdb isn't impressed by the above improved debug and still prints
(gdb) ptype zzz
type = char *[]
compared to the following when omitting the declaration.
(gdb) ptype zzz
type = char *[2]
so it seems to ignore the seemingly redundant DW_AT_type in the
specification DIE. The DWARF spec isn't entirely clear what is
to be taken from the specification and what from the declaration DIE
and how to handle this situation. But the wording suggests that
"completing" something is exactly the use-case for a specification
(whether that applies to completing a referenced DIE as in this case
remains an open question).
gdb folks?
