[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||mark at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from Mark Wielaard --- 10.1 is long since released
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Mark Wielaard changed: What|Removed |Added CC||gccbugs at dima dot secretsauce.ne ||t --- Comment #8 from Mark Wielaard --- *** Bug 78100 has been marked as a duplicate of this bug. ***
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Richard Biener changed: What|Removed |Added Known to work||10.0 Known to fail|10.0| --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 --- Comment #6 from Alexandre Oliva --- Author: aoliva Date: Tue Oct 1 11:36:31 2019 New Revision: 276403 URL: https://gcc.gnu.org/viewcvs?rev=276403=gcc=rev Log: DWARF array bounds missing from C++ array definitions A variable redeclaration or definition that provides additional type information for it, e.g. outermost array bounds, is not reflected in the debug information for the variable. With this patch, the debug info of the variable specialization gets a type attribute with the adjusted type. This patch affects mostly only array bounds. However, when the symbolic type used in a declaration and in a definition are different, although they refer to the same type, debug information will end up (correctly?) naming different symbolic types in the specification and the definition. Also, when a readonly declaration of an array loses the readonly flag at the definition because of the initializer, the definition may end up referencing a type while the specification refers to a const-qualified version of that type. If the type of the variable is already const-qualified, e.g. an array of a const type, the difference is meaningless. for gcc/ChangeLog PR debug/91507 * dwarf2out.c (override_type_for_decl_p): New. (gen_variable_die): Use it. for gcc/testsuite/ChangeLog PR debug/91507 * gcc.dg/debug/dwarf2/array-0.c: New. * gcc.dg/debug/dwarf2/array-1.c: New. * gcc.dg/debug/dwarf2/array-2.c: New. * gcc.dg/debug/dwarf2/array-3.c: New. * g++.dg/debug/dwarf2/array-0.C: New. * g++.dg/debug/dwarf2/array-1.C: New. * g++.dg/debug/dwarf2/array-2.C: New. Based on libstdc++-v3's src/c++98/pool_allocator.cc:__pool_alloc_base::_S_heap_size. * g++.dg/debug/dwarf2/array-3.C: New. Based on gcc's config/i386/i386-features.c:xlogue_layout::s_instances. * g++.dg/debug/dwarf2/array-4.C: New. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/array-0.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/array-1.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/array-2.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/array-3.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/array-4.C trunk/gcc/testsuite/gcc.dg/debug/dwarf2/array-0.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/array-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/array-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/array-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 --- Comment #5 from Tom de Vries --- patch submitted: https://sourceware.org/ml/gdb-patches/2019-09/msg00161.html
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Richard Biener changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24971 --- Comment #4 from Richard Biener --- I've opened a gdb bug, maybe I can get clarification that way.
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 --- Comment #3 from Richard Biener --- Note that lldb has (lldb) p zzz (char *[2]) $0 = ([0] = "abc", [1] = "cde") for the proposed variant with an extra DW_AT_type in the specification DIE and (lldb) p zzz error: incomplete type 'char *[]' where a complete type is required for the variant GCC currently generates.
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507
Richard Biener 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 ---
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?
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Richard Biener changed: What|Removed |Added Keywords||wrong-debug CC||jsm28 at gcc dot gnu.org Known to fail||10.0, 9.2.1 --- Comment #1 from Richard Biener --- And the C frontend confuses dwarf2out here by calling dwarf2out_early_global_decl twice with the same decl but with different unrelated TREE_TYPE of it. There's of couse no way it can be expected to recover from that? I guess the situation can only arise for decls at global scope? So we could in theory try to lookup the DIE for the decls type after looking up a specification DIE and emit a new DIE for it? Ideally we'd have marked the earlier DIE as "incomplete" somehow.
