On Sun, 8 May 2022, 00:09 Paul Smith, <paul@xxxxxxxxxxxxxxxxx> wrote: > On Sat, 2022-05-07 at 20:51 +0100, Jonathan Wakely wrote: > > On Sat, 7 May 2022 at 20:07, Paul Smith <paul@xxxxxxxxxxxxxxxxx> > > wrote: > > GCC's 'make install' should do everything needed. That installs > > $prefix/lib64/libstdc++.so.6.0.30-gdb.py alongside the .so file, and > > gdb auto-loads that when debugging a process linked to the > > libstdc++.so.6.0.30 library. That python script imports the > > register_libstdcxx_printers function and runs it. > > > > Maybe you're only linking statically to libstdc++.a? > > Ah. Yes I'm linking statically. > > > Hmm, that's reminiscent of > > https://sourceware.org/bugzilla/show_bug.cgi?id=25234 > > I checked and when I first attach I do see: > > (gdb) show lang > The current source language is "auto; currently c". > > and things don't work, then after I change to a C++ frame I see: > > (gdb) show lang > The current source language is "auto; currently c++". > > and things work. > > I discovered that if I add: > > set language c++ > > to my init, that it all works properly. For my purposes this is a > sufficient workaround. > > It's a bit strange (confusing) that the C++ pretty-printers work > without having to do that, but the C++ xmethods do not. > > Also just a data point, my previous GDB (10.2) didn't require this: > when I attach with that version, GDB chose the auto language as "c++" > immediately. I suppose it's worth a bugzilla report. > > > All the logic to do that in Python is already present in the > > printers, > > I figured so I'd hoped there was something here already. I get what > you're saying of course. Maybe I'll find some time to dig into this... > at some point... > > > > (b) Ways to access the contents of containers like unique_ptr, > > > shared_ptr, etc. from python functions. So if in my class I have > > > "std::unique_ptr<Foo> fooPtr" and in my python functions I have a > > > variable "fooPtr" which refers to this object, I would like a way > > > to retrieve a gdb.Value containing its pointer. > > > > The UniquePtrGetWorker Xmethod already does that. You should be able > > to just do: > > > > py ptr = gdb.parse_and_eval('uniqptr.get()') > > xmethods don't help me (IIUC) because I'm in the middle of some Python > function and the value I want to retrieve is in a Python variable, not > in a GDB variable, so I can't easily access it with parse_and_eval(). > > For instance in my examples here I'd have a python method: > > def find_obj(val): > if val['mgr']['initialized']: > return val['mgr'] > return val['otherMgr'] > > or whatever, but of course I can't do this because val['mgr'] is a > std::unique_ptr and I don't know how to dig out the object it points > to. The above doesn't need to work as-is: something like: > > def find_obj(val): > mgr = StdUnique(val['mgr']).get() > if mgr['initialized']: > return mgr > return val['otherMgr'] > > or whatever would be fine. > gdb.set_convenience_variable('mgr', val['mgr']) init = gdb.parse_and_eval('$mgr->initialized') This will use the xmethod to evaluate the expression. >
