[Bug python/27510] New: Document gdb.Type string representations

[Bug python/27510] New: Document gdb.Type string representations

[jwakely.gcc at gmail dot com]

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

            Bug ID: 27510
           Summary: Document gdb.Type string representations
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: python
          Assignee: unassigned at sourceware dot org
          Reporter: jwakely.gcc at gmail dot com
  Target Milestone: ---

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

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

[Bug python/27510] Document gdb.Type string representations

[jwakely.gcc at gmail dot com]

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

--- Comment #1 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
Created attachment 13283
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13283&action=edit
Patch for python.texi

I think this addresses all my comments above, assuming I've understood the
semantics correctly.

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

[Bug python/27510] Document gdb.Type string representations

[hi-angel at yandex dot ru]

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

Hi-Angel <hi-angel at yandex dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hi-angel at yandex dot ru

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

[Bug python/27510] Document gdb.Type string representations

[jwakely.gcc at gmail dot com]

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

--- Comment #2 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
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?

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

[Bug python/27510] Document gdb.Type string representations

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #3 from Hannes Domani <ssbssa at sourceware dot org> ---
(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.

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