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 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).
>
> As a random example of GDB returning different gdb.Values for the same
> thing:
>
> > $ gdb --quiet `which cat`
> > Reading symbols from /bin/cat...Reading symbols from /usr/lib64/debug/bin/cat.debug...done.
> > done.
> > (gdb) start
> > Temporary breakpoint 1 at 0x401d7b: file cat.c, line 502.
> > Starting program: /bin/cat
> >
> > Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe068) 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)
That's really an unrelated example, IMO.
> 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.
Yes, we should keep those working.
> I hope this makes more sense now because I don't think I can explain it
> any better :(.
Yes, thanks.
> > > and probably causes exactly the same problems for the MI.
> >
> > 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.
--
Pedro Alves