https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
--- Comment #3 from Jeff Garrett <jeff at jgarrett dot org> ---
That's such a good point about the local types in general.
Considering that the gdb python API seems to prefer readable names, e.g. for
lookup, and those are not standard nor unique, might it be perhaps preferable
to avoid going through the regex to get the manager type, and from that the
contained type? Something like this?
mgr = self.val['_M_manager']
if mgr != 0:
# cast to uintptr_t doesn't seem to be necessary
func = gdb.block_for_pc(long(mgr))
if not func:
raise ValueError("Invalid function pointer in %s" %
self.typename)
self.contained_type = gdb.lookup_symbol('_Tp', func)[0].type
valptr = None
mgrfuncname = func.function.name
if
mgrfuncname.startswith('{0}::_Manager_internal'.format(self.typename)):
valptr = self.val['_M_storage']['_M_buffer'].address
elif
mgrfuncname.startswith('{0}::_Manager_external'.format(self.typename)):
valptr = self.val['_M_storage']['_M_ptr']
else:
raise ValueError("Unknown manager function in %s" %
self.typename)
contained_value =
valptr.cast(self.contained_type.pointer()).dereference()
We can lookup the symbol for the formal template parameter of the manager by
its name ('_Tp') in the context of the block for the _S_manage function. I'm
not an expert in any of this, so there may be a reason this is not preferable.
It does seem to work with some fundamental types and std::string as well (with
no magic to handle the typedef).
It still fails in the multiple local lambdas case... But that seems like an
easier to solve problem, because I believe the DWARF debugging has enough
information to know which lambda is _Tp in each of the instantiations, and gdb
is just getting confused. I think it should work in principle.
