On 18 December 2016 at 02:08, Paul Smith <paul@xxxxxxxxxxxxxxxxx> wrote: > 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? Not that I know of. It's unlikely to happen unless somebody contributes the work. > 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 what you're suggesting, could you give an example of what you mean? > I'm not sure how exactly this would work (can you create Python > objects and set GDB convenience variables for them...?) Yes. > 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. What are the issues with debugging containers?
