This is the mail archive of the gcc-help@gcc.gnu.org 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: Compat: Missing things from libstdc++-v3/python/libstdcxx/v6/printers.py


On 18 December 2016 at 02:08, Paul Smith <paul@mad-scientist.net> 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?


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