This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Python, pretty printing, frame decorators and MI


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]