From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21616 invoked by alias); 16 Aug 2011 22:12:07 -0000 Received: (qmail 21494 invoked by uid 22791); 16 Aug 2011 22:12:06 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from adoakley.name (HELO ado.is-a-geek.net) (46.4.104.242) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Aug 2011 22:11:51 +0000 Received: from ado-gentoo.moore.slainvet.net ([2001:8b0:393:0:223:54ff:fe39:b789] helo=ado-gentoo) by ado.is-a-geek.net with esmtpa (Exim 4.76) (envelope-from ) id 1QtRpI-0006s2-QI; Tue, 16 Aug 2011 22:09:37 +0000 Date: Tue, 16 Aug 2011 22:12:00 -0000 From: Andrew Oakley To: Pedro Alves Cc: gdb@sourceware.org Subject: Re: Python API - nested pretty printers MI implications Message-ID: <20110816231151.6cd06011@ado-gentoo> In-Reply-To: <201108151530.08237.pedro@codesourcery.com> References: <20110814171023.19db4f49@ado-gentoo> <201108151357.50298.pedro@codesourcery.com> <4E4927D2.2050903@ado.is-a-geek.net> <201108151530.08237.pedro@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-08/txt/msg00062.txt.bz2 On Mon, 15 Aug 2011 15:30:08 +0100 Pedro Alves wrote: > On Monday 15 August 2011 15:06:10, Andrew Oakley wrote: > > I assume the idea is to create a gdb.Value (with some data it > > doesn't really matter what) and then detect that it is that > > particular gdb.Value when the pretty printers list is searched? > > Perhaps you could do something like this: > >=20 > > def fake_value_printer(val): > > if hasattr(val, "prettyprinter"): > > return val.prettyprinter > > else: > > return None > >=20 > > gdb.pretty_printers.insert(0, fake_value_printer) > >=20 > > Then you could just return any old gdb.Value and as long as it had a > > prettyprinter attribute then that would be called instead of the > > "normal" version. > >=20 > > Is this what you were thinking of? >=20 > I was actually thinking more like: >=20 > gdb.pretty_printers.insert(0, fake_value_printer) >=20 > def fake_value_printer(val): > isinstance(o, MyFakeValue) > return FakeValuePrinter(val, or whatever args needed) > else: > return None >=20 > instead of duck typing, but yes, that sounds similar. >=20 > > That's quite a nice trick but I'm not sure its a good long-term > > solution. It relies on the same python gdb.Value being passed back > > to the pretty printer selection function=20 >=20 > I don't understand. Imagine for a minute that a "struct value" didn't have a reference to a gdb.Value. Instead a gdb.Value is created every time we want to pass a value to python. The result of this is that the pretty-printer could return one gdb.Value and the pretty printer selection function would get a completely different gdb.Value that represented the same thing (breaking any code that worked like the examples above).=20=20 Given that GDB is quite happy giving you different gdb.Value objects for exactly the same thing it doesn't seem unreasonable to expect it to happen with pretty printers too (and the documentation doesn't say that it can't happen). As a random example of GDB returning different gdb.Values for the same=20 thing: > $ gdb --quiet `which cat` > Reading symbols from /bin/cat...Reading symbols from /usr/lib64/debug/bin= /cat.debug...done.=20 > done. > (gdb) start > Temporary breakpoint 1 at 0x401d7b: file cat.c, line 502. > Starting program: /bin/cat=20 >=20 > Temporary breakpoint 1, main (argc=3D1, argv=3D0x7fffffffe068) at cat.c:5 > 502 cat.c: No such file or directory. > in cat.c > (gdb) python print gdb.selected_frame().read_var('argc') is gdb.selected_= frame().read_var('argc') > False > (gdb)=20 Given some changes to the MI I can envisage this actually happening in reality, Daniel Jacobowitz was talking about allowing non-root object updates which might lead to this kind of behaviour.=20=20 I hope this makes more sense now because I don't think I can explain it any better :(. > > and probably causes exactly the same problems for the MI. >=20 > There'd be no NULL values this way. Wasn't that the problem? Kind of. Unfortunately this could well confuse front ends. They see something that looks like a real value, it even has a type they can "helpfully" display. That's not good because this isn't a real value so we shouldn't make the FE (and by extension varobj) think that it is. > > Back to my initial question I guess for MI this is also creating a > > "dummy" varobj with some type and value chosen by the python > > script. Do you know if this works in practice with MI frontends? >=20 > I'm not sure what you mean. You'd always need a "dummy" varobj > for each of the "fake values", wouldn't you? (I'm not sure you've > seen my reply to Andr=C3=A9 though). Again, it's a question of whether the varobj knows it is fake or not. I'd prefer it if the varobj did know (even if this isn't exposed over MI for now). --=20 Andrew Oakley