This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Compat: Missing things from libstdc++-v3/python/libstdcxx/v6/printers.py
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paul Smith <paul at mad-scientist dot net>
- Cc: gcc-help <gcc-help at gcc dot gnu dot org>
- Date: Sun, 18 Dec 2016 23:22:13 +0000
- Subject: Re: Compat: Missing things from libstdc++-v3/python/libstdcxx/v6/printers.py
- Authentication-results: sourceware.org; auth=none
- References: <1481658564.4268.143.camel@mad-scientist.net> <CAH6eHdT=F2orhrgdyMUKZTncBXTh=DBwTcb=NETYLC8v_g+jxg@mail.gmail.com> <1482026929.4552.71.camel@mad-scientist.net>
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?