This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: block of commands
- From: Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Sun, 24 Jan 2016 23:25:23 +0100
- Subject: Re: RFC: block of commands
- Authentication-results: sourceware.org; auth=none
- References: <001a1143804e6a9e8f0529ce089a at google dot com> <1453499357 dot 2097 dot 18 dot camel at skynet dot be> <CADPb22S7u6YinHKSh-keg8SvP8d4847BLVW1Gqqf-RyJbVM=Ww at mail dot gmail dot com>
On Sun, 2016-01-24 at 12:03 -0800, Doug Evans wrote:
> On Fri, Jan 22, 2016 at 1:49 PM, Philippe Waroquiers
> <philippe.waroquiers@skynet.be> wrote:
> >
> >
> > I think that effectively, the principles you suggest below
> > should allow to make a reasonable syntax, and no backward
> > incompatibility.
> > So basically:
> > * trailing } is mandatory
> > * inside a block of commands, { } and ; must be escaped
> > * a command block is limited to be on a single line
> > I guess multiple lines will be ok if each line is terminated
> > by a \.
> >
> > The above principles should also allow to extend if/while/...
> > to have 'one line' if/while/...
> >
> > I also think that 'one line if' will allow to do things such as:
> >
> > thread apply all if $ebp -$esp > 1000000 { echo big frame in this thread }
> >
> > (today, trying to use an 'if' in thread apply gives a quite strange
> > behaviour : the rest of the 'if' command is read during each execution
> > for each thread, which is not very user friendly :).
> >
> > I will work based on the above idea, and resubmit a draft patch
> > but that will for sure have to wait after FOSDEM, which
> > will already consume the night and week-end free time :).
> >
> > Thanks for the comments/help/nice suggestions
> >
>
>
> Hi.
> Sounds like a plan, but in an effort to make your time
> as productive as I can I would suggest first trying to come
> up with syntax that the community can accept.
Good idea, the plan is easier to write than the code.
>
> Among the questions we need to answer:
> - when/how to escape { } ;
> (what I gave was a strawman, I didn't dig deep
> into whether there are any gotchas)
> - what to do with { } in expressions,
> e.g., "if ({1,2,3})[2] == 3 { echo foo }"
> - ???
Here are some more details/answers:
Basic syntax
------------
Block of commands are single line, trailing } are mandatory.
These conditions are needed to allow to extend existing commands
(thread apply, if, while) in a (reasonably) backward compatible way.
The parsing of command blocks will be deferred to the commands
that accepts block of commands (or commands) as parameters.
Commands in a block are separated by ;.
; is optional in front of a { or a }, e.g.
{ echo 1\n { echo 2\n; echo 3\n ; } echo 4\n }
Escaping:
---------
{ } ; must be escaped inside a block of commands in order
to lose their 'block of command special character semantic'.
A single \ is good enough to escape, no need to have a \ for each
nesting level, e.g.
thread apply all { echo \{ at nesting 1 { echo \; at nesting 2 } }
No need to escape in expressions which are 'at nesting 0', e.g.
if ({1,2,3})[2] == 3 { echo foo }
The 'if' command parser will search for a trailing }
and will parse backward to search the matching opening {, counting
nesting levels. So, thanks to backward parsing, {}; do not need to
be escaped in expressions.
Only problem I see with this are expressions that are
terminated with a }.
Then the parser might confuse such an expression in an
'end terminated if' with a block of command of
a 'single line' if.
So, probably we will have to handle escaping the final } of such an
expression.
However, that will be a backward incompatibility.
I guess this incompatibility is unlikely, unless there is a language
where } are often terminating an expression ?
I do not see how to avoid this (unlikely?) backward incompatibility.
When 'if' is used inside a command block, then special characters
in the expression must be escaped e.g.
thread apply all { if (\{1,2,3\})[2] == 3 { echo three } }
Error handling
--------------
{/s ... }
means to continue executing the block if a command fails;
all the output of failing commands are silently ignored.
{/c .... }
also means to continue executing the block if a command fails,
but the error is reported.
Extension of existing commands
------------------------------
Commands that have a command as parameter or read other commands
will be extended to accept a block of commands (which must be
at the end of the line).
So:
thread apply all { .... }
if expression { ... } [else { ... } }
while expression { ... }
Is there something else to extend ?
Maybe single line define such as
define helloworld { echo hello; echo world\n }
?
Have a way to silence some commands using optional /s marker
------------------------------------------------------------
E.g.
thread apply all /s command
means that a thread is shown only if command has produced some output
Some new commands
-----------------
As discussed, new command
frame apply all
accepting also an optional /s
For completeness, I guess we better have:
inferior apply all ....
(and optional /s marker)
The idea is that all the above can be combined e.g.
inferior apply all /s { thread apply all /s { frame apply all /s if condition { echo look at this inferior/thread/frame }}}
(long single lines like that can be broken in separate lines using \ at the end of the line).
Note: I guess that the parser of inferior/thread/frame apply all
can be a 'forward parser', and so the first two { will be optional for the above.
Otherwise, inferior/thread/frame will also look for a terminating } and do a backward
parsing, then in the above example, all { } are needed to allow backward parsing.
I would have preferred to avoid the (unlikely I hope) incompatibility of }
terminated expressions, but I do not see a reasonable way to do that.
Comments/remarks/plan-killer-bugs/... welcome.
Philippe