From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F11AE388A426; Thu, 4 Mar 2021 13:00:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F11AE388A426 From: "jwakely.gcc at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug python/27510] New: Document gdb.Type string representations Date: Thu, 04 Mar 2021 13:00:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: python X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jwakely.gcc at gmail dot com 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: 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 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 13:00:17 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27510 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 versio= ns) or gdb.Type.tag or str(gdb.Type). The docs do not really say what the vario= us strings contain, particularly for C++ class types, with possible cv-qualifi= ers 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 is= n't suitable as an argument to the gdb.lookup_type function. It doesn't drop cv-qualifiers, e.g.=20 (gdb) py print(gdb.lookup_type('int').const()) const int The difference between gdb.Type.name and gdb.Type.tag is unclear, except th= at 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 explici= tly. Given: int main() { struct S {} s; using C =3D const S; C c =3D 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=20 Temporary breakpoint 1, main () at test.C:6 6 return 0; (gdb) py s =3D gdb.parse_and_eval('s'); c =3D 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 --=20 You are receiving this mail because: You are on the CC list for the bug.=