Re: [RFC] mi: add -a option to the "-data-disassemble" command

[Jan Vrany <jan dot vrany at fit dot cvut dot cz>]

On Fri, 2018-08-10 at 10:47 +0100, Pedro Alves wrote:
> On 08/10/2018 09:29 AM, Jan Vrany wrote:
> > @@ -33095,6 +33101,9 @@ records, produced when trying to execute an undefined @sc{gdb/mi} command
> >  @item exec-run-start-option
> >  Indicates that the @code{-exec-run} command supports the @option{--start}
> >  option (@pxref{GDB/MI Program Execution}).
> > +@item data-disassemble-a-option
> > +Indicates that the @code{-data-disassemble} command supports the @option{-a}
> > +option (@pxref{GDB/MI Data Manipulation}).
> >  @end ftable
> 
> I'm curious about how you intend to use this new -list-features feature.
> Are you enabling/disabling some UI element depending on presence of the
> feature?  I.e., something that you wouldn't be able to do by just
> trying the "-data-disassemble -a" command and looking for error?

Yes. Basically I have a menu item on frame that opens another window with
disassembly of the coresponding function (showing current instruction, 
(basic) blocks and alike). 

For programs with debug information, I can do that even without -a option. 
For programs without debug information, I need -a option and - to make the
frontend robust w.r.t UX - I disable the menu item. 

I can indeed just try and catch the error, but this seems to be too heavyweight.
It would mean to disassemble function whenever user switches frames in the 
UI or in CLI. I can cache the result, but still. This new feature just makes
it trivial and fast enough (no MI roundtrip to enable/disable menu item)

That being said, I do not insist on having this feature. I'm close to the point
of just saying "you need to use my patched GDB, anyway.  At least for "now" and 
hope that my patches will eventually make it into official GDB release. Not a big 
deal for me, not at all. 

So, if you (meaning you maintainers) prefer not having this feature, I'll just remove 
it. Absolutely no problem! Just let me know. 

Jan