From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id AC5CE3858D20; Wed, 29 May 2024 09:49:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AC5CE3858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1716976182;
	bh=CXrBSL/lT8CnTeKujoIPN4FRxvioFfPWOXXIiZltHR8=;
	h=From:To:Subject:Date:From;
	b=nXCa+Q+NPBAF2XnLybEelAiIp2zL8cQquQ7TGtHT/xINDF8IseYa/9wmZMoKIfO4P
	 /8qny4bny/wC5aObCfJDsNob1lh3xHPOzFadaeuaJyurr6CdM6kpHkjYyBp17Xos/m
	 yo5RLIe93rJB2/zJhAcV+fgqP00XjsnrlIWIDVzE=
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/115272] New: [debug] complex type is hard to related back
 to base type
Date: Wed, 29 May 2024 09:49:42 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-115272-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

            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 =3D 0
type =3D float
$2 =3D 0
type =3D double
$3 =3D 0
type =3D double
...

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

I submitted a fix for gdb that achieves this here (
https://sourceware.org/pipermail/gdb-patches/2024-May/209415.html ).  The f=
ix
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 in=
fo.

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 solu=
tion
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, bu=
t we
could add this as an extension.=