[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.