[Bug symtab/30845] New: Make gdb more tolerant for slightly different type strings in C++

[Bug symtab/30845] New: Make gdb more tolerant for slightly different type strings in C++

[plasmahh at gmx dot net]

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

            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 crafted
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 versions
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 type
clear. 

For example, writing in code 

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

will produce the symbol 

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 

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

Note how the integer is using the single ticks as well as the suffix, and the
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).

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

[Bug symtab/30845] Make gdb more tolerant for slightly different type strings in C++

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-09-13
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
cp-name-parser.y needs some updates

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

[Bug symtab/30845] Make gdb more tolerant for slightly different type strings in C++

[tromey at sourceware dot org]

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

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
I suppose there are two bugs here.
I have a patch for the separator problem but not the ">>" problem.

Name canonicalization is somewhat fragile as C++ evolves.
There may not be a good way to do better though.

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

[Bug symtab/30845] Make gdb more tolerant for slightly different type strings in C++

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a4b7c5f5cda16795dd8be11494e8f1b5de21d69f

commit a4b7c5f5cda16795dd8be11494e8f1b5de21d69f
Author: Tom Tromey <tom@tromey.com>
Date:   Fri Apr 19 20:22:11 2024 -0600

    Implement C++14 numeric separators

    C++14 allows the use of the apostrophe as a numeric separator; that
    is, "23000" and "23'000" represent the same number.  This patch
    implements this for gdb's C++ parser and the C++ name canonicalizer.

    I did this unconditionally for all C variants because I think it's
    unambiguous.

    For the name canonicalizer, there's at least one compiler that can
    emit constants with this form, see bug 30845.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845
    Approved-By: John Baldwin <jhb@FreeBSD.org>

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

[Bug symtab/30845] Make gdb more tolerant for slightly different type strings in C++

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.1
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
Fixed.

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