Bug 27510 - Document gdb.Type string representations
Summary: Document gdb.Type string representations
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: python (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-04 13:00 UTC by Jonathan Wakely
Modified: 2021-03-05 13:50 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Patch for python.texi (994 bytes, patch)
2021-03-04 13:04 UTC, Jonathan Wakely
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Wakely 2021-03-04 13:00:16 UTC
Re https://sourceware.org/gdb/current/onlinedocs/gdb/Types-In-Python.html

We've had numerous libstdc++ bugs in the python printers that are due to me failing to use the right string representation of a type. I find it unclear whether I should use gdb.Type.name (which isn't present in older GDB versions) or gdb.Type.tag or str(gdb.Type). The docs do not really say what the various strings contain, particularly for C++ class types, with possible cv-qualifiers present.

The conversion to String is completely undocumented. On IRC I was told that it's similar to whatis/r s, which seems to be true. I'm told that for some combinations of GCC and GDB that string includes "class", which means it isn't suitable as an argument to the gdb.lookup_type function. It doesn't drop cv-qualifiers, e.g. 

(gdb) py print(gdb.lookup_type('int').const())
const int

The difference between gdb.Type.name and gdb.Type.tag is unclear, except that gdb.Type.name doesn't exist in older GDB versions (which could be documented too), and for non-class types (e.g. integer types and functions) there is no tag e.g.

(gdb) py print(gdb.lookup_type('int').tag)
None
(gdb) py print(gdb.lookup_type('int').name)
int

As far as I can tell, both drop cv-qualifiers:

(gdb) py print(gdb.lookup_type('int').const().name)
int

They seem to be the same for class and enumeration types. But a typedef for a class has a name but no tag, which makes sense, but could be stated explicitly.

Given:

int main()
{
  struct S {} s;
  using C = const S;
  C c = S();
  return 0;
}


I get this with GDB 9.1:

$ gdb -q -ex start  a.out
Reading symbols from a.out...
Temporary breakpoint 1 at 0x401106: file test.C, line 6.
Starting program: /tmp/a.out 

Temporary breakpoint 1, main () at test.C:6
6         return 0;
(gdb) py s = gdb.parse_and_eval('s'); c = gdb.parse_and_eval('c')
(gdb) py print(s.type)
S
(gdb) py print(s.type.tag)
S
(gdb) py print(s.type.name)
S
(gdb) py print(c.type)
C
(gdb) py print(c.type.tag)
None
(gdb) py print(c.type.name)
C
(gdb) py print(c.type.strip_typedefs())
const S
(gdb) py print(c.type.strip_typedefs().name)
S
(gdb) py print(c.type.strip_typedefs().tag)
S
Comment 1 Jonathan Wakely 2021-03-04 13:04:24 UTC
Created attachment 13283 [details]
Patch for python.texi

I think this addresses all my comments above, assuming I've understood the semantics correctly.
Comment 2 Jonathan Wakely 2021-03-04 14:28:00 UTC
But to make things more complicated ...

echo 'struct S { } s;' > test.C
g++ -g -c test.C -o test1.o
echo 'int main() { }' >> test.C
g++ -g -c test.C -o test2.o

gdb -q -ex 'py print(gdb.lookup_type("S"))' -ex q test1.o
Reading symbols from test1.o...
struct S

gdb -q -ex 'py print(gdb.lookup_type("S"))' -ex q test2.o
Reading symbols from test2.o...
S

WAT?

Whether str(gdb.Type) includes the "struct" class-head depends on whether main() is defined in the same translation unit? How does that make sense?

It is at least consistent with 'whatis':

gdb -q -ex 'whatis s' -ex q test1.o
Reading symbols from test1.o...
type = struct S

gdb -q -ex 'whatis s' -ex q test2.o
Reading symbols from test2.o...
type = S

But ... why?
Comment 3 Hannes Domani 2021-03-05 13:50:30 UTC
(In reply to Jonathan Wakely from comment #2)
> But to make things more complicated ...
> 
> echo 'struct S { } s;' > test.C
> g++ -g -c test.C -o test1.o
> echo 'int main() { }' >> test.C
> g++ -g -c test.C -o test2.o
> 
> gdb -q -ex 'py print(gdb.lookup_type("S"))' -ex q test1.o
> Reading symbols from test1.o...
> struct S
> 
> gdb -q -ex 'py print(gdb.lookup_type("S"))' -ex q test2.o
> Reading symbols from test2.o...
> S
> 
> WAT?
> 
> Whether str(gdb.Type) includes the "struct" class-head depends on whether
> main() is defined in the same translation unit? How does that make sense?

This behavior started with gdb-8.2, with 8.1.1 it says just 'S' for both.