Python API - nested pretty printers MI implications

Pedro Alves
Mon Aug 15 14:30:00 GMT 2011

On Monday 15 August 2011 15:06:10, Andrew Oakley wrote:
> On 15/08/11 13:57, Pedro Alves wrote:
> > On Sunday 14 August 2011 17:10:23, Andrew Oakley wrote:
> >>         def children(self):
> >>                 yield ("normal variable", "some value")
> >>                 yield ("phony group 1", inner_pretty_printer(...))
> >>                 yield ("phony group 2", inner_pretty_printer(...))
> >>
> >> This seems to work well but I'm not quite sure how to handle the for MI.
> >>
> >> As far as I can tell I need to create "fake" varobj structures with no
> >> underlying value or type (because I don't have one). 
> > 
> > I'm not very familiar with the pretty printing stuff, but,
> > doesn't something like this work nowadays?
> [snip]
> > That is, create a specialized Value class and install the pretty
> > printer for that _value_.
> This didn't come up when I asked about this previously.
> 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:
> def fake_value_printer(val):
> 	if hasattr(val, "prettyprinter"):
> 		return val.prettyprinter
> 	else:
> 		return None
> gdb.pretty_printers.insert(0, fake_value_printer)
> 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.
> Is this what you were thinking of?

I was actually thinking more like:

gdb.pretty_printers.insert(0, fake_value_printer)

def fake_value_printer(val):
   isinstance(o, MyFakeValue)
		return FakeValuePrinter(val, or whatever args needed)
 		return None

instead of duck typing, but yes, that sounds similar.

> 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 

I don't understand.

> and probably causes exactly the same problems for the MI.

There'd be no NULL values this way.  Wasn't that the problem?

> 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?

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é though).

Pedro Alves

More information about the Gdb mailing list