This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: issue with GDB python pretty-printers for libstdc++

On Wed, 26 Feb 2020 at 14:32, Paul Smith <> wrote:
> Hi all.  I was seeing a strange error in GDB (8.2.1) debugging some C++
> code while trying to print a value.  The pretty printer was throwing Python
> exceptions.
> Debugging it I discovered the problem, which is here (from GCC 9.2):
> libstdc++-v3/python/libstdcxx/v6/
>   # Starting with the type ORIG, search for the member type NAME.  This
>   # handles searching upward through superclasses.  This is needed to
>   # work around
>   def find_type(orig, name):
>       typ = orig.strip_typedefs()
>       while True:
>           # Strip cv-qualifiers.  PR 67440.
> -->       search = '%s::%s' % (typ.unqualified(), name)
>           try:
>               return gdb.lookup_type(search)
>           except RuntimeError:
>               pass
>           # The type was not found, so try the superclass.  We only need
>           # to check the first superclass, so we don't bother with
>           # anything fancier here.
>           field = typ.fields()[0]
> (First that GDB bug was fixed in 2012 so I'm not sure if we still need this
> method, but anyway...)
> The issue is on the marked line above.  Here we are using the __str__()
> method on a gdb.Type to obtain the string name of the type.  However, I've
> discovered that (at least on my system) the __str__() representation of a
> gdb.Type prepends the keyword "class " or "struct " (as appropriate) to the
> output.  So the above will result in a string like:
>   search = 'class std::unordered_map...::...'

I don't think I've seen that problem before. Are you sure that's the
cause, and not something like ?

> The prepended "class " causes the code to break: it doesn't find the type,
> then we try to use typ.fields()[0] which doesn't work as follows:
>   Traceback (most recent call last):
>       ...
>     File "/cc/python/libstdcxx/v6/", line 97, in find_type
>       field = typ.fields()[0]
>   IndexError: list index out of range
> I think that it's not correct for the Python macros here to be using the
> gdb.Type.__str__() method to obtain the type name for anything other than
> displaying to users.  They should always be using the data
> member instead.  If I change the marked line above to be:
>       search = '%s::%s' % (typ.unqualified().name, name)
> then it all works as expected.
> However, I took a quick look through the code and it _appears_ to me that
> this type of thing (using the implied, or explicit, gdb.Type.__str__() to
> obtain the type name) is done in a number of places.

I'm never clear whether we should be using or Type.tag or
Type.__str__() because they all seem to do the wrong thing in
different situations.

> This makes me wonder whether (a) for some reason no one noticed this
> before, or (b) there's something bizarre about my GDB which is prepending
> this "class" or "struct" where other peoples' don't do that?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]