Re: [PATCH] MI: Allow non-raw varobj evaluation

Leszek Swirski via gdb-patches
2018-01-25T11:11:25Z

On Thu, Jan 25, 2018 at 2:53 AM, Simon Marchi <simon.marchi@polymtl.ca> wrote:
>
> Could you give an example to reproduce this problem? I tried with a vector of vector, but -var-evaluate-expression just prints "{...}":
>
> -var-evaluate-expression var1
> ^done,value="{...}"
>
> so I am not sure what problem you are after.

Hi Simon,

So, this is a bit of an edge case, which I encountered with the
chromium pretty printers. Effectively, it's when a pretty printer
returns another object in its to_string, rather than a string.

Consider the following code:

struct Foo { int val; };
struct Wrapper { Foo foo; };

int main() {
Wrapper w;
w.foo.val = 23;
}

and this pretty printer file:

import gdb.printing

class FooPrinter:
def __init__(self, val):
self.val = val
def to_string(self):
return "Foo" + str(self.val["val"])

class WrapperPrinter:
def __init__(self, val):
self.val = val
def to_string(self):
return self.val["foo"]

test_printer = gdb.printing.RegexpCollectionPrettyPrinter("test")
test_printer.add_printer('Foo', '^Foo$', FooPrinter)
test_printer.add_printer('Wrapper', '^Wrapper$', WrapperPrinter)

gdb.printing.register_pretty_printer(None, test_printer)

Setting a breakpoint at the end of the function, we call the following commands:

-enable-pretty-printing
^done

-var-create var_w @ w
^done,name="var_w",numchild="0",value="{val =
23}",type="Wrapper",dynamic="1",has_more="0"
-var-create var_w_foo @ w.foo
^done,name="var_w_foo",numchild="0",value="Foo23",type="Foo",dynamic="1",has_more="0"

-var-evaluate-expression var_w
^done,value="{val = 23}"
-var-evaluate-expression var_w_foo
^done,value="Foo23"

-data-evaluate-expression w
^done,value="Foo23"
-data-evaluate-expression w.foo
^done,value="Foo23"

So, in the -var-evaluate-expression var_w case, we print the "raw"
value of w.foo, while in the -data-evaluate-expression w case, we
print the pretty printed w.foo value. After my patch, all of the above
print "Foo23".

Note that this isn't encountered very often, probably because it
disappears if I replace `return self.val["foo"]` with `return
str(self.val["foo"])`. But, it does feel like the wrong behaviour.

- Leszek