This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Python, pretty printing, frame decorators and MI
- From: Jan Vrany <jan dot vrany at fit dot cvut dot cz>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Cc: Didier Nadeau <didier dot nadeau at polymtl dot ca>
- Date: Thu, 15 Jun 2017 21:22:44 +0100
- Subject: Re: Python, pretty printing, frame decorators and MI
- Authentication-results: sourceware.org; auth=none
- References: <1497477981.14398.14.camel@fit.cvut.cz> <2ef610c7b532194be6372e53aa3101c9@polymtl.ca>
Hi,
On Thu, 2017-06-15 at 13:23 +0200, Simon Marchi wrote:
> On 2017-06-15 00:06, Jan Vrany wrote:
> > Hi there,
> >
> > to ease debugging, I have a set of python pretty printers and frame
> > decorators - they work fine and print internal structures nicely.
> >
> > I also have a custom frontend using MI. I want to reuse these
> > python
> > printers / decorators in the frontend. This way I don't need to
> > duplicate the code of pretty printer on top of MI.
> >
> > The problem is that if I enable pretty printing / frame filters in
> > MI,
> > I no longer get the "raw" values, only pretty printed.
> >
> > For example, let's say I have a pretty printer for type OBJ
> > (pointer to
> > a struct) which prints "0x12345678 (Symbol: #x:y:)" while without
> > pretty printer it would just print "0x12345678".
> > Similar happens for frame decorators. Once I enable frame
> > filters/decorators, I no longer have access (on MI level) to raw
> > function name as in DRARF debug info.
> >
> > How difficult would be to extend MI to provide both
> > representations?
> > The idea is to provide another "property" with "raw"
> > represenstation.
> > This way it'd be backward compatible as MI frontends are expected
> > to
> > ignore unknown properties.
> >
> > Could you give me some pointers/hints where to look GDB code in
> > order
> > to (try to) add this functionality?
>
> I don't know if it's already possible to get what you want, if it is
> perhaps somebody else will reply with an answer.
>
> Otherwise, it shouldn't be too difficult to prototype the
> functionality
> you are describing. If you are interested in modifying the output
> of
> the -var-evaluate-expression command, for example, start at
> mi_cmd_var_evaluate_expression in mi/mi-cmd-var.c and follow the
> code
> from there.
>
> I can't tell you what's the best design for this (because I don't
> know
> the answer :)). I think the best way to proceed is to try some
> things
> on your side, come up with a concrete proposal of the changes you'd
> like
> to bring, and then we can discuss about that.
I;ll have look. Thanks very much for hints!
>
> > Would it be also possible to allow Python to define new MI commands
> > in
> > addition to CLI commands?
>
> I think it would be a very cool feature. There was a submission to
> implement that by Didier Nadeau:
>
> https://sourceware.org/ml/gdb-patches/2017-02/msg00283.html
>
> I think it's also available here if you want to try it:
>
> https://github.com/nadeaud/binutils-gdb/commits/python-mi
>
> I don't know if Didier will have time to follow-up with it, I added
> him
> in CC so he can reply himself. If he doesn't plan to follow-up, and
> you
> want to pick up where he left off, I'm sure there will be no problem.
>
Awesome! My dreams were true even before I dreamed them! I'll have a
look, for sure.
Thanks a lot! Jan