Re: [RFA 0/8] Implement 'frame apply COMMAND', enhance 'thread apply COMMAND'

[Pedro Alves <palves at redhat dot com>]

On 06/04/2018 09:56 PM, Philippe Waroquiers wrote:
> On Mon, 2018-06-04 at 17:46 +0100, Pedro Alves wrote:

>>
>> 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.

Yeah.  I haven't tried converting the explicit locations
parser to the new framework, because that parser is very
tricky.

> 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.

Not as bad IMHO, but true regardless.

> 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'

Yeah.  Traditionally GDB makes it so that old common shorthands continue
working.  It's the same with command names too.  E.g., "t" for "thread",
even though "t" is ambiguous.  So I see the options following the
same principle.


>>> 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.

Ah, the joys of text communication misunderstandings.
No need to apologize, I was just kidding.  :-)

>>> 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.

Interesting.  I wonder whether it would make sense to
give some example like this in the manual.

> 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 ?

Yes, it does.  Thanks for doing all this!

Pedro Alves