From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 31C293858C66; Wed, 13 Sep 2023 07:55:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 31C293858C66
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1694591759;
	bh=/Jp0XpLQ2kONv5dMeq/TiRuVX6z0Q11tCHMBEpUtDyY=;
	h=From:To:Subject:Date:From;
	b=qBBygZS4jIt0B+eVISzdvEd+LolRqOZ7tYc6RhU2g15EkGupiSsLv5Z8m9NLOliK8
	 XxUYBUI5zgu55tG9ZS6bUIXVmvVyBn6hEyyabkcRvjl6qoaLEphjtesHPlMizxBxyf
	 tuObqAhTmtZQhKp/zWVXz5g5H7Cybmw5Qb07Wu3U=
From: "plasmahh at gmx dot net" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug symtab/30845] New: Make gdb more tolerant for slightly
 different type strings in C++
Date: Wed, 13 Sep 2023 07:55:58 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: symtab
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: plasmahh at gmx dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot 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-30845-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D30845

            Bug ID: 30845
           Summary: Make gdb more tolerant for slightly different type
                    strings in C++
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: plasmahh at gmx dot net
  Target Milestone: ---

I am not sure if this is 100% correct, but in the end the point is that the
type text for commands like ptype or casting to something should work better
for strings generated by (other) compilers ( and maybe as well as hand craf=
ted
ones ).

As far as I can see it, the informtion from "info types" as well as the one
displayed when e.g. printing the address of an object with "p &var" is
assembled from compiler provided strings. These can differ slightly from the
way gdb expects type strings.

For example, a type output from gcc like "D<D<D<int> > >" will be written as
"D<D<D<int>>>" in the IAR compiler. gdb does not like that string and says =
"A
syntax error in expression, near `>>'." ... Maybe because in ancient versio=
ns
of C++ >> was not supported? Anyways, it would be nice if gdb could support
both ways.

On a similar note, compilers like IAR like to output integers as template
arguments in a way you would probably write them in code too, to make the t=
ype
clear.=20

For example, writing in code=20

std::conditional_t<true, uint64_t, std::chrono::nanoseconds>

will produce the symbol=20

std::conditional<true, unsigned long long, std::chrono::duration<long long,
std::ratio<1, 1000000000> > >

when compiled with gcc, but when compiled with IAR it looks like=20

conditional<true, unsigned long long, std::chrono::duration<signed long lon=
g,
std::ratio<1LL, 1'000'000'000LL>>>

Note how the integer is using the single ticks as well as the suffix, and t=
he
long long is explicitly naming the signed.


In the end, gdb should ideally always be able to take the output of "p &var"
and parse it correctly to yield something that you can then use ( e.g. to p
again).

--=20
You are receiving this mail because:
You are on the CC list for the bug.=