From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119655 invoked by alias); 25 Jan 2018 11:11:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 119237 invoked by uid 89); 25 Jan 2018 11:11:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mail-yb0-f177.google.com Received: from mail-yb0-f177.google.com (HELO mail-yb0-f177.google.com) (209.85.213.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Jan 2018 11:11:23 +0000 Received: by mail-yb0-f177.google.com with SMTP id k127so2831563ybc.12 for ; Thu, 25 Jan 2018 03:11:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DXfAtwQuGMWh4EpNmDWOVyzwrN8d0Ynx91XPAdrlC2c=; b=nwNWJa/7Cmu0lc2Rt1ZmUG+6BUML89/VfXXI96sCeoa7CnU7LpB5Bqo65KCP9bXgHV MUsvryzUq9eMcRK4jf4WHYSuYvJuBaXtiIUXzdq0v2ZeVVFwcb4/TU8xCsyuvD4frJcZ 55ayq1hUUSkHyd1f9Rq4kUb6Gxv5uK0DdfQw4BjfS0qJvsiVy+3LGe8ZJW0Yk9osInOd HMfWgRXr82dqGxE8VdJEZ+Roe+Libui5JBCNXaxPnFBal0M8Qv852jHAUKETXcgnhdl5 vFufHjKZ0bkMNivNUVe4VXUPRywlezKlwa9Cv5wKY5Gu5u8zA+Od/IztDYmUg4aoUNp8 LpWw== X-Gm-Message-State: AKwxytdBL72C+GpqIjSqxHMVKIvY9SpGwK4/aX9tD1FqQbUTIGgcIRlq qlUVlFmb8ET4IfxblUcqnpzQEw2eo58n48zSkEeNeBe9kiQ= X-Google-Smtp-Source: AH8x226Xw0amAMzTAv+D0MezcA4es7NYrPr+hMdcpd/7UGZgXAMtzIJFaBlze8GvlCwpu+LUg70A5HWNQyDYTRce4co= X-Received: by 10.37.201.196 with SMTP id z187mr8083078ybf.250.1516878681345; Thu, 25 Jan 2018 03:11:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.133.141 with HTTP; Thu, 25 Jan 2018 03:11:00 -0800 (PST) In-Reply-To: <9bc195e52123f5d878778ebebd074ee4@polymtl.ca> References: <20180124173223.213808-1-leszeks@google.com> <9bc195e52123f5d878778ebebd074ee4@polymtl.ca> From: "Leszek Swirski via gdb-patches" Reply-To: Leszek Swirski Date: Thu, 25 Jan 2018 11:11:00 -0000 Message-ID: Subject: Re: [PATCH] MI: Allow non-raw varobj evaluation To: Simon Marchi Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-01/txt/msg00516.txt.bz2 On Thu, Jan 25, 2018 at 2:53 AM, Simon Marchi 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