This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Python API - nested pretty printers MI implications
On Wed, 17 Aug 2011 13:49:10 +0100
Pedro Alves <pedro@codesourcery.com> wrote:
> On Tuesday 16 August 2011 23:11:51, Andrew Oakley wrote:
> >
> > On Mon, 15 Aug 2011 15:30:08 +0100
> > Pedro Alves <pedro@codesourcery.com> 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:
> > > >
> > > > 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) else:
> > > 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.
> >
> > 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).
>
> I understand now, thanks. Actually, it looks like that is already
> happening, as when gdb always takes a copy of the struct value
> under the gdb.Value internally, and then wraps it in a _new_ gdb.Value
> before passing it to the python pretty printer lookup functions (in
> the pretty_printers array). :-( IMO this is a bug, and the internal
> conversions should be short-circuited to garantee the same gdb.Value
> is passed ...
>
> (I remembered <http://sourceware.org/ml/gdb/2010-09/msg00125.html>,
> which ended up in gdb.Value being extendable, but I see that Tom had
> identified the internal copy problem at the time too.)
>
> > 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).
Now I have this information would it be better to attempt to fix the
internal copy "problem" rather than continuing with the current changes
that try to allow a pretty printer to be returned directly?
Obviously documentation should be updated to indicate that you can rely
on this behaviour (once any problems have been fixed) but a lot of
scary things might go away.
> > > 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.
>
> Not sure that's a real problem. We could maybe just make it type
> void.
If I was wanting to write my own FE I would certainly want to know. On
the other hand I have no intention of doing that so I guess it depends
on what others think.
Perhaps we could simply have a convention that fake values have a
"void" type (assuming that can be done) so the FE can detect them if it
wants to but it shouldn't break anything. I think should satisfy
everybody.
--
Andrew Oakley