On Sat, 7 May 2022 at 16:08, Paul Smith <paul@xxxxxxxxxxxxxxxxx> wrote:
>
> On Sat, 2022-05-07 at 11:19 +0000, Hannes Domani wrote:
> > > The only thing I've found that works is just to access the pointer
> > > value directly by cutting and pasting it with a cast:
> > >
> > > (gdb) p *((Mgr*)0x7f519a24e000)
> > > $8 = {
> > > ...
> > > initialized = true
> > > }
> > >
> > > (gdb) p ((Mgr*)0x7f519a24e000)->initialized
> > > $9 = true
> > >
> > > Is that really what we have to do?
> >
> > I'm assuming you installed the pretty printers with a call to
> > register_libstdcxx_printers() somewhere.
> > For access to C++ STL objects there is another set of gdb helpers,
> > called xmethods, which you need to install with a call to
> > register_libstdcxx_xmethods().
>
> Thanks for the reply. I should have mentioned this; what I do is:
>
> python
> from libstdcxx.v6 import register_libstdcxx_printers
> register_libstdcxx_printers(None)
> end
Why are you doing this by hand? That should not be necessary.
>
> That method loads both the pretty printers AND the xmethods:
>
> # Load the xmethods if GDB supports them.
> def gdb_has_xmethods():
> try:
> import gdb.xmethod
> return True
> except ImportError:
> return False
>
> def register_libstdcxx_printers(obj):
> # Load the pretty-printers.
> from .printers import register_libstdcxx_printers
> register_libstdcxx_printers(obj)
>
> if gdb_has_xmethods():
> from .xmethods import register_libstdcxx_xmethods
> register_libstdcxx_xmethods(obj)
>
> Just to verify I've tried explicitly loading and calling
> register_libstdcxx_xmethods() and I get an error saying they're already
> loaded.
>
> Just to clarify are you saying that one or both of the methods I've
> tried (using * or -> operators) _should_ work, and that they do work
> for you when you try them?
Yes.
>
> If so then I guess I'm doing something wrong and I will have to look
> more deeply.
>
> > > Secondly, is there some interface that is defined by the
> > > libstdcxx.v6 Python macros for GDB that people who are doing their
> > > own python scripting for their own C++ programs can take advantage
> > > of to avoid too much groveling through the depths of the C++ STL
> > > implementation?
> >
> > Depends on what you want to do with it, but you can get access to the
> > pretty printers in gdb with a call to gdb.default_visualizer() [1].
>
> I'm not talking about printing things per se, I'm talking about writing
> my own python macros that help me examine my own data structures, which
> are built with STL types.
>
> For example I have a complex structure that uses std::vector,
> std::list, std:unordered_map, unique_ptr, etc. and I want to write my
> own methods that examine these structures, either to print them in a
> different way (not just the standard pretty-printer output) or
> whatever.
That sounds useful, but it's unlikely anybody else is going to provide
it. If you want it, you get to build it :-)
>
> So I have a Python variable containing a pointer to this object that
> contains a unique_ptr, and I want to get a variable containing the
> pointer contained in the unique_ptr. How do I do that? Is there some
> Python function available in the macros that will do that for me?
Still no macros anywhere here :-)
>
> As I said in my previous message, with GCC 11 it doesn't seem like I
> can just get the _M_head_impl value any longer, as I get these
> "ambiguous" failures.
>
> Basically I can't use any of the new versions of GCC until I can figure
> out how to debug them in a reasonable way.
(gdb) p *static_cast<std::_Head_base<0, Mgr*,
false>&>(p->mgr._M_t._M_t)._M_head_impl
$10 = {initialized = true}
