Re: Python, pretty printing, frame decorators and MI

Hi,

thanks for your reply! I'm certainly interested. I tried to 
rebase your changes on top of a current master. I failed 
so far, mostly because my poor C++ knowledge, but still 
trying when time allows. 

Best, Jan

On Thu, 2017-08-03 at 11:41 -0400, Didier Nadeau wrote:
> Hi,
> 
> Sorry for the dealy, I completely missed the message, but I am very
> happy to hear there is interest for the patch. I will check if I need
> to submit the patch and re-submit it to the mailing list !
> 
> Thank you,
> 
> Didier
> 
> 2017-06-15 16:22 GMT-04:00 Jan Vrany <[email protected]>:
> > 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