[Bug debug/115272] New: [debug] complex type is hard to related back to base type

[Bug debug/115272] New: [debug] complex type is hard to related back to base type

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272

            Bug ID: 115272
           Summary: [debug] complex type is hard to related back to base
                    type
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test.c:
...
$ cat test.c
__complex__ float cf;
__complex__ double cd;
__complex__ long double cld;
...
compiled using an arm-linux-gnueabihf target compiler:
...
$ gcc test.c -g -c
...

The three types are represented like this:
...
 <1><2e>: Abbrev Number: 2 (DW_TAG_base_type)
    <2f>   DW_AT_byte_size   : 8
    <30>   DW_AT_encoding    : 3        (complex float)
    <30>   DW_AT_name        : complex float
 <1><44>: Abbrev Number: 2 (DW_TAG_base_type)
    <45>   DW_AT_byte_size   : 16
    <46>   DW_AT_encoding    : 3        (complex float)
    <46>   DW_AT_name        : complex double
 <1><5b>: Abbrev Number: 2 (DW_TAG_base_type)
    <5c>   DW_AT_byte_size   : 16
    <5d>   DW_AT_encoding    : 3        (complex float)
    <5d>   DW_AT_name        : (indirect string, offset: 0): complex long
double
...

Note that the sizes of complex double and complex long double are the same.

When printing the type of the real component in gdb, we get:
...
$ gdb -q -batch test.o \
    -ex 'p $_creal(cf)' -ex 'ptype $' \
    -ex 'p $_creal(cd)' -ex 'ptype $' \
    -ex 'p $_creal(cld)' -ex 'ptype $'
$1 = 0
type = float
$2 = 0
type = double
$3 = 0
type = double
...

We'd prefer to get "long double" for the real component of complex long double.

I submitted a fix for gdb that achieves this here (
https://sourceware.org/pipermail/gdb-patches/2024-May/209415.html ).  The fix
involves grepping for "long" in the name of the complex type, which is hacky
and fragile, but it's the best we can do with the current state of debug info.

If gcc would emit a DW_AT_type pointing to the component type, this could be
solved cleanly and unambiguously. [ Note: this was also discussed as a solution
to PR93988, but a different solution was chosen there (
https://dwarfstd.org/issues/210218.2.html ). ]

As things stand, a DW_TAG_base_type is not allowed to have a DW_AT_type, but we
could add this as an extension.

[Bug debug/115272] [debug] complex type is hard to related back to base type

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
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?

[Bug debug/115272] [debug] complex type is hard to related back to base type

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(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

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
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

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(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.