This is the mail archive of the mailing list for the Archer 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]

[python] Should pretty-printer affect resulting gdb-history value?


Consider this source:

(gdb) list 
1       int main()
2       {
3         struct S { int *ptr; } s;
4         int i = 42;
6         s.ptr = &i;
7         return 0;
8       }

The 'struct S' is emulating some kind of smart pointer here.

Let's say the user is always interested in s.ptr when he looks at
'struct S', and so installs a pretty-printer for it:

(gdb) shell cat
class SPrinter:
        "Print S struct"

        def __init__(self, val):
                self.val = val

        def to_string(self):
                return self.val['ptr'];

gdb.pretty_printers['^struct S$'] = lambda val: SPrinter(val)

(gdb) source
(gdb) b 7
Breakpoint 1 at 0x40031f: file t.c, line 7.
(gdb) r

Breakpoint 1, main () at t.c:7
7         return 0;

(gdb) print/r s
$1 = {ptr = 0x7fffffffe5dc}

(gdb) print s.ptr
$2 = (int *) 0x7fffffffe5dc

(gdb) print s
$3 = 0x7fffffffe5dc          # pretty-printer worked,
                             # but why didn't it also print "(int *)" ?

(gdb) whatis $3              # not at all what I would have expected...
type = struct S

(gdb) print *$3
Structure has no component named operator*.

The result above is particularly disconcerting (though it makes
sense given the type of $3): if the user wants to dereference the
smart pointer, he now has to go back to raw representation, and 
"fish out" the implementation bits.

I think it would make sense for the type of $2 and $3 to match,
though I have no idea whether that's implementable.


Paul Pluzhnikov

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