Re: Python, pretty printing, frame decorators and MI

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