On Fri, 16 Dec 2016 13:33:52 +0100, Jonathan Wakely wrote:
> We don't do auto-deref for std::shared_ptr or std::unique_ptr, even
> though we know the object they point to definitely is live and safe to
> access, and that's because those types have pointer semantics not
> reference semantics.
This is wrong std::shared_ptr or std::unique_ptr is not auto-dereferenced for
GDB printing. But it may be more a GDB problem, not libstdc++ pretty printers
problem.
For example glib pretty printers already auto-dereference data structures:
5 GList* list = NULL;
(gdb) p/r list
$1 = (GList *) 0x607a00
(gdb) p list
$2 = 0x607a00 = {0x400810}
/usr/share/glib-2.0/gdb/glib.py
if type.code == gdb.TYPE_CODE_PTR:
type = type.target().unqualified()
t = str(type)
if t == "GList":
return GListPrinter(val, "GList")
But that is more a GDB bug that should be solved even for generic pointers.
Currently while traversing through data structures one has to randomly add or
remove '*' from the beginning of the GDB print expression:
1 class E { int a[1000]; int i=42; } ee;
2 class D { E *e=ⅇ } dd;
3 class C { D &d=dd; } cc;
4 class B { C *c=&cc; } bb;
5 int main() {}
(gdb) p bb
$1 = {c = 0x601030 <cc>}
(gdb) p bb.c
$2 = (C *) 0x601030 <cc>
Oops, I need to add a dereference:
(gdb) p *bb.c
$3 = {d = @0x601028}
(gdb) p *bb.c.d
No symbol "operator*" in current context.
Oops, I need to remove a dereference:
(gdb) p bb.c.d
$4 = (D &) @0x601028: {e = 0x601060 <ee>}
(gdb) p bb.c.d.e
$5 = (E *) 0x601060 <ee>
Oops, I need to add a dereference:
(gdb) p *bb.c.d.e
$6 = {a = {0 <repeats 1000 times>}, i = 42}
(gdb) p *bb.c.d.e.i
Cannot access memory at address 0x2a
Oops, I need to remove a dereference:
(gdb) p bb.c.d.e.i
$7 = 42
This is probably solved in some clickable front-end interfaces.
Jan
