[Bug debug/115272] [debug] complex type is hard to related back to base type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 --- Comment #5 from Tom de Vries --- (In reply to Tom de Vries from comment #4) > With this patch: So, would this approach be acceptable? If so, I can put effort into doing a proper submission.
[Bug debug/115272] [debug] complex type is hard to related back to base type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272
--- Comment #4 from Tom de Vries ---
With this patch:
...
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 8ec3856873e..ea3318396e0 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -13247,6 +13247,7 @@ base_type_die (tree type, bool reverse)
bool fpt_used = false;
struct fixed_point_type_info fpt_info;
tree type_bias = NULL_TREE;
+ tree type_attr = NULL_TREE;
/* If this is a subtype that should not be emitted as a subrange type,
use the base type. See subrange_type_for_debug_p. */
@@ -13342,6 +13343,8 @@ base_type_die (tree type, bool reverse)
}
else
encoding = DW_ATE_lo_user;
+ if (!dwarf_strict)
+ type_attr = TREE_TYPE (type);
break;
case BOOLEAN_TYPE:
@@ -13421,6 +13424,13 @@ base_type_die (tree type, bool reverse)
| dw_scalar_form_reference,
NULL);
+ if (type_attr != NULL_TREE)
+{
+ dw_die_ref type_attr_die
+ = modified_type_die (type_attr, 0, reverse, comp_unit_die ());
+ add_AT_die_ref (base_type_result, DW_AT_type, type_attr_die);
+}
+
return base_type_result;
}
...
on x86_64 we get:
...
<1><32>: Abbrev Number: 2 (DW_TAG_base_type)
<33> DW_AT_byte_size : 4
<34> DW_AT_encoding: 4(float)
<34> DW_AT_name: float
<1><38>: Abbrev Number: 3 (DW_TAG_base_type)
<39> DW_AT_byte_size : 8
<3a> DW_AT_encoding: 3(complex float)
<3a> DW_AT_type: <0x32>
<3e> DW_AT_name: complex float
<1><56>: Abbrev Number: 2 (DW_TAG_base_type)
<57> DW_AT_byte_size : 8
<58> DW_AT_encoding: 4(float)
<58> DW_AT_name: double
<1><5c>: Abbrev Number: 3 (DW_TAG_base_type)
<5d> DW_AT_byte_size : 16
<5e> DW_AT_encoding: 3(complex float)
<5e> DW_AT_type: <0x56>
<62> DW_AT_name: complex double
<1><7b>: Abbrev Number: 2 (DW_TAG_base_type)
<7c> DW_AT_byte_size : 16
<7d> DW_AT_encoding: 4(float)
<7d> DW_AT_name: long double
<1><81>: Abbrev Number: 3 (DW_TAG_base_type)
<82> DW_AT_byte_size : 32
<83> DW_AT_encoding: 3(complex float)
<83> DW_AT_type: <0x7b>
<87> DW_AT_name: complex long double
...
[Bug debug/115272] [debug] complex type is hard to related back to base type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 --- Comment #3 from Tom de Vries --- (In reply to Richard Biener from comment #2) > (In reply to Richard Biener from comment #1) > > How does it work for 'double' vs. 'long double' themselves? > > > > <1><32>: Abbrev Number: 3 (DW_TAG_base_type) > > <33> DW_AT_byte_size : 16 > > <34> DW_AT_encoding: 4(float) > > <35> DW_AT_name: (indirect string, offset: 0x60): long double > > > > so if it's not distinguishable via DW_AT_byte_size you look into > > DW_AT_name as well? For complex types there's a need to get at the base type, for scalar types there's not, so I'm not sure I understand the question. > So it looks like doing the same for _Complex long double > > is perfectly in line? > > Take for example powerpc with it's dual IEEE and IBM long double 128 format. [ See also PR 104194. ] That's slightly different, in the sense that in this PR we're trying to distinguish the two distinct base types of two distinct types: "complex double" and "complex long double". With "dual IEEE" and "IBM long double 128 format", there's a single type, long double, that can have different formats, with different ABIs. GDB handles this distinction by looking up Tag_GNU_Power_ABI_FP in the elf file.
[Bug debug/115272] [debug] complex type is hard to related back to base type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 --- Comment #2 from Richard Biener --- (In reply to Richard Biener from comment #1) > How does it work for 'double' vs. 'long double' themselves? > > <1><32>: Abbrev Number: 3 (DW_TAG_base_type) > <33> DW_AT_byte_size : 16 > <34> DW_AT_encoding: 4(float) > <35> DW_AT_name: (indirect string, offset: 0x60): long double > > so if it's not distinguishable via DW_AT_byte_size you look into > DW_AT_name as well? So it looks like doing the same for _Complex long double > is perfectly in line? Take for example powerpc with it's dual IEEE and IBM long double 128 format.
[Bug debug/115272] [debug] complex type is hard to related back to base type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 --- Comment #1 from Richard Biener --- How does it work for 'double' vs. 'long double' themselves? <1><32>: Abbrev Number: 3 (DW_TAG_base_type) <33> DW_AT_byte_size : 16 <34> DW_AT_encoding: 4(float) <35> DW_AT_name: (indirect string, offset: 0x60): long double so if it's not distinguishable via DW_AT_byte_size you look into DW_AT_name as well? So it looks like doing the same for _Complex long double is perfectly in line?
