Re: Types prefixed by "class" or "struct" string??

Paul Smith
2020-02-21T18:16:57Z

On Fri, 2020-02-21 at 09:55 -0500, Paul Koning wrote:
> > But, if I try to look up the type including the "class " it
> > definitely fails:
>
> Well, sure. "class" is not part of the name of the type.

Heh. Well, clearly :). I think I didn't make something clear in my
initial message: it's not *ME* that's providing the "class " prefix:
GDB is doing that itself. That's the problem: it's adding this prefix
to the names of types, then when it tries to look them up it fails.

However I've discovered the culprit, although I still can't understand
why I never saw this before / what could have changed.

Basically, if you evaluate a gdb.Type in a string context GDB adds the
"class" or "struct" prefix; I guess that's part of the __str__
representation for the gdb.Type class?

Example:

(gdb) python
> o = gdb.convenience_variable('o')
> print o['pending'].type
> ^D
class std::__cxx11::list<Object::Pending, std::allocator<Object::Pending> >

But if I use the .name attribute, then I don't get the prefix:

(gdb) python
> o = gdb.convenience_variable('o')
> print o['pending'].type.name
> ^D
std::__cxx11::list<Object::Pending, std::allocator<Object::Pending> >

Unfortunately the Python macros that come with GCC's STL use the string
conversion in the pretty-printer code; for example:

def find_type(orig, name):
typ = orig.strip_typedefs()
while True:
# Strip cv-qualifiers. PR 67440.
search = '%s::%s' % (typ.unqualified(), name)

If this used type.unqualified().name instead it would probably be OK.

But, this kind of thing is done EVERYWHERE in the GCC pretty-printers
so it can't possibly have always been this way or nothing would work!!

I simply don't understand how I could have not run into such a
fundamental issue before: as I said I've been using all these same
versions, built locally and checked into Git, for well over a year now.

Has GDB always provided this "class" / "struct" prefix in the __str__
representation of gdb.Type?