Compat: Missing things from libstdc++-v3/python/libstdcxx/v6/printers.py

Paul Smith paul@mad-scientist.net
Sun Dec 18 02:09:00 GMT 2016


On Wed, 2016-12-14 at 11:06 +0000, Jonathan Wakely wrote:
> > In other words if I take the latest set of printer macros from dev HEAD
> > and start using them with GCC 6.2 (I use -std=gnu++14), are they
> > intended to work (modulo bugs)?
> 
> In most cases yes, because a program being debugged might contain a
> mix of code compiled by different GCC versions, so the printers need
> to support the container implementations from previous GCC versions.
> 
> However, that isn't tested, so could break, and there are exceptions
> to the rule. One that springs to mind is that in GCC 5
> std::experimental::any can be constructed with an allocator, and the
> printers grok such an object. In GCC 6 the allocator support was
> removed from the type and from the printers, so the GCC 6 printers
> cannot display a std::Experimental::any compiled with GCC 5 and
> constructed with an allocator.

That's OK, I jumped straight from 4.9.2 to 6.2.0 :).  I only care about
6.2.0 right now.

Thanks Jonathan, that's what I anticipated.


I have another question.  Has anyone given consideration to providing a
full complement of xmethods for all the STL types in GDB, even if they
don't immediately translate into a real STL method?

For example in real code I wouldn't normally use a std::list then
attempt to access the 15th element, very often, but I can see it being
handy/useful to be able to use mylist[15] and retrieve the 15th element
in a std::list, inside the debugger.

Also it would be nice if there were some way of creating a "debugger
iterator", implemented for all the basic STL types that would allow us
to iterate over them from within the debugger, including with core
files.  I'm not sure how exactly this would work (can you create Python
objects and set GDB convenience variables for them...?)

Has anyone looked into anything like that?  For us issues with debugging
STL types have been a main reason for reluctance to let go of home-grown 
basic types.



More information about the Gcc-help mailing list