This is the mail archive of the 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


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,


2017-06-15 16:22 GMT-04:00 Jan Vrany <>:
> 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:
>> I think it's also available here if you want to try it:
>> 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]