This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 0/8] Implement 'frame apply COMMAND', enhance 'thread apply COMMAND'
On Mon, 2018-06-04 at 17:46 +0100, Pedro Alves wrote:
> On 06/01/2018 08:38 PM, Philippe Waroquiers wrote:
> > Based on the above, it is not very clear what is the
> > 'less unusual' usual way to specify flags/options
>
> It should at least be clear that single-'-' is used throughout,
> while double-'-' like gnuopt does (by default) for long options
> is never used, except in the '--' terminator.
Yes.
>
> The explicit location options for example, is a clear
> example of more modern GDB options. There, we accept
> "break -function", "break -line", etc. and all abbreviations,
> like "b -fun", "b -f", etc.
When I looked, I did not discover this case of
'long options starting with a -, and that can be abbreviated'.
I thought long options were all like 'thread apply -ascending'
and could not be abbreviated.
> And very importantly, we
> support TAB completion of command options. I think that's
> the killer feature. It helps with the typing _and_ the
> discoverability of the user interface. I.e., you can
> type "b -TAB" to see all the options you can pass to the
> command. I'd like to be able to have that for _all_ commands.
Yes, that would be very nice.
>
> >
> > In parallel, I have started another patch to have e.g.
> > info var [-t TYPE_REGEXP ] REGEXP
> > to only show the var having a type matching TYPE_REGEXP
> > This is showing yet another difficulty: how to put a space
> > in an argument ?
>
> Unless it's the last/rightmost argument, then I think the
> best choice is to have the user quote or escape if
> necessary?
Yes, that should work, and is better/more intuitive.
>
> Note that "b -function foo (int) -line 10" works, even
> though there's a space in "foo (int)", because the explicit
> location's parser was taught to skip past function names,
> and in that case, we know that ()s are balanced. But it's
> tricky code, and the same probably can't be done for
> REGEXPs, I think.
Such arg parsing intelligence might make a
generic parser framework somewhat more tricky,
or at least the generic framework will have to "know"
the syntax of all such specially parsed options,
or maybe delegate the parsing of some arguments
to some arg specific code depending on the option type,
which can then make e.g. the -- end of option recognition
to be done at several places.
And effectively, see where a REGEXP terminates and see
where the next REGEXP starts is not doable without
quoting.
>
> >
> > At that point, it looked like one of my next patch should
> > be an 'option/argument parser', basically the same as what
> > you describe above with the 'generic framework for command
> > options'. This framework should provide option parsing
> > and argument parsing, and allow optional quoting.
> > IMO, we better base this as much as possible to be
> > similar to the usual getopt, with at least the following
> > differences:
> > * for backward compatibility, we should support sometimes
> > alternative backward compatible behaviour, together with
> > a new 'standard behaviour' e.g.
> > backtrace [--full | -f | full ] ....
> > or
> > thread apply all [--ascending | -a | -ascending ]
>
> That's basically unlike any command option in GDB currently.
> We've settled on single-'-' a long time ago, so I'm not
> seeing how breaking that buys us much other than another
> long partial transition, lots of confusion and breaking
> scripts and user habits.
The above idea was supposed to be backward compatible,
but is completely broken by the fact that long single - options
can be abbreviated.
>
> Because we currently accept single '-' as long option
> specifier, I don't see how we can both keep backward
> compatibility with current "b -function" etc, _and_
> allow single '-' as specifier for
> short-options-that-can-be-combined, because that causes ambiguity
> like, what does "(gdb) cmd -fu" mean:
>
> #1 - (gdb) cmd -function
> #2 - (gdb) cmd -function -unique
>
> ?
>
> I don't think that saying 'it's "-function" if "-unique" doesn't
> exist yet', because then we need worry about the fact that adding
> any option can break any abbreviated use of existing options.
Agreed.
Note we already have some worry with the current status:
E.g. break -l meaning depends on how many options
starts with -l, and in which order the code checks them.
If break was accepting initially only -line,
and -label is added as a new option : if the code first
checks for -label, then -l will change of semantic
and/or cause an error.
Note that the doc for break says the abbreviation must have
the unique prefix characters, but that of course
depends on the future options being added
(and today, break -l is accepted and interpreted as break -line).
Note that getopt does not accept ambiguity e.g. :
$ ls --a
ls: option '--a' is ambiguous; possibilities: '--all' '--author' '--almost-all'
> > * have a way to (explicitely) quote an argument e.g.
> > info var -Qt 'long int' regexpofsomevars
> > where -Q indicates that the next "value argument" is
> > explicitely quoted.
>
> Not sure we need that -Q. We can support optional quotes, and
> tell users to add quotes if necessary? That's what we've done
> since forever in linespecs and expressions, for example.
Yes I think that should work.
>
> > * allow combining short one letter args such as -cs
> > but also allow -c -s
>
> I think that way lies madness.
Yes, that looks clear to me now that I know about
abbreviated long single - options.
> As mentioned above, I think the combining the short options under
> a single '-' is problematic. As such, I'd rather see that removed
> from the patch, and the flags implemented as regular
> individually-specified options. I.e., have the user type "-s -c"
> instead of "-sc".
Agreed : we cannot have both abbreviated long single - option
and have combined
short options.
>
> > If we assume that
> > the 'long single -' option (such as -ascending) cannot be
> > abbreviated,
>
> I don't think that's desirable. I think making GDB support
> "-ascending" abbreviations would be an obviously desirable patch.
>
> > then I think we can make something backward compatible
> > but go to a more uniform option/arg parsing (and avoid
> > 'local' re-implementation of option parsing logic such as
> > skip spaces etc).
> > Of course, if in this patchn, we mandate -v -v -c -s
> > instead of -vvcs, that would be equally compatible with the
> > future option/arg parser
> > ('future' is the politically correct synonym of vapourware :).
>
> I resent the "vapourware" remark. :-P It's real! :-P
Humph, sorry. I wanted to indicate my own suggestion
(a getopt like parser for --longoptions) was vapourware.
I clearly understood you produced some real code ...
> I wrote most of this about 6 months ago, and haven't
> context switched it all back in, but I think I wanted to
> look to see if we could share more for point #2 above.
>
> I encourage you (and others) to give it a try, particularly
> play with TAB completion, see how that makes options more
> discoverable and the CLI a better joy. IMO.
And the examples you give looks really nice ...
>
> > I could not make an alias that was specifying -s or any option,
> > e.g.
> > (gdb) alias inta = interrupt -a
> > Invalid command to alias to: interrupt -a
> > (gdb)
>
> That sounds like something we should fix, regardless.
Ok. I have added this to my list of things to do one of these
week-ends ...
>
> > and I found e.g.
> > t a a -s f a a -s
> > quite long to type, and so worth the aliases.
>
> I wonder whether that's a real use case in practice though.
> What sort of thing does one want to print in all frames
> of all threads? Genuinely curious.
The idea is to let gdb discover where a certain variable
or argument exists and can be printed.
This helps when things are optimised out in one frame,
but can be printed in upper frames (or upper
scope/nested blocks in Ada).
Another possible use case is something like :
tfaas info local -t sometype
to see all local vars in all frames of all threads
that have the given type. For example, sometype
might be an RAII type that locks whatever :
this is then a quick way to discover all active locks.
'info local -t TYPEREGEXP' is a patch I am working on,
but I am waiting an agreement on this patch
to RFC/RFA it ...
More generally, the idea is to let gdb find where a command
can be run successfully.
The plan (almost but not fully vapourware :)) is e.g. to allow the below :
thread apply all -s frame apply all -s if somecondition { some other gdb commands }
or whatever COMMAND that can succeed (or fail) in a frame.
{ and } is the idea of the 'block command' prototype I did a long time ago,
from where this 'apply a command to all frames' originates.
Depending on week-end free time, I will re-start the block of commands
work.
>
> >
> > > > An example usage :
> > > > tfaas p some_local_var_somewhere
> > > > same as the longer:
> > > > 'thread apply all -s frame apply all -s p some_local_var_somewhere'
>
> I could bite that, even though it looks a bit contrived to me.
>
> Thanks,
> Pedro Alves
At this point, it looks clear to me we better do not allow
combined short options. If we want to support combined short options
one day, then as you suggested, we need another syntax to combine them:
frame apply all /cvv p somevar
In the meantime, I can rework the patch to (only) accept separately
the -c -s -v -q flags.
Does that sound like a correct plan to you ?
Thanks
Philippe