Re: [RFC/WIP PATCH 00/14] I/T sets (resend)

["Tomas Östlund" <tomas.ostlund@ericsson.com>]

On 02/09/12 15:35, Pedro Alves wrote:
[...]
> 
> Great.  I actually implemented most of this.
> 
> See the v2 (latest version) of the series at:
> 
>  http://sourceware.org/ml/gdb-patches/2011-12/msg00550.html

Thanks, I will check that out.

> 
> The problem is one of ambiguity when you want to be able to specify
> sets as an option, and support other options.  E.g.,
> 
> break -stop foo bar qux
> 
> -stop takes a set as argument.  Is the set "foo", or "foo bar"?  Perhaps
> even "foo bar qux"?  You'd need to quote the set somehow, like
> 
> break -stop 'foo bar' qux.
> 
> which we were trying to avoid (just like []'s)
> 
> We could allow optional quoting.  Another alternative would be to use some
> other characters.  I don't know, '.', and ',' seemed quite intuitive to me.  Maybe
> you could try v2 out a bit.  It's still easily accessible in my git, as pointed
> out in the v2 series intro.

I'm not sure I see what the problem is here. If you compare to a UNIX shell, you have 
the same kind of issue that you sometimes need to quote in order to be unambiguous. 

For example, using the grep command as an example:

> grep foo bar froz

will grep for the string "foo" in the files bar and froz.

On the other hand, in order to search for the string "foo bar" in the file froz you 
need to quote like

> grep "foo bar" froz.

The idea is that you do not need to *always* quote as was the case with the brackets
in the HPD spec, only when the command is ambiguous. So I think it is perfectly fine 
to expect the user to somehow quote the argument to the -stop flag like

break -stop 'foo bar' qux

or

break -stop foo,bar qux

> 
> It kind of follows from the idea that you can also switch the
> set focus permanently.  With "itfocus" in v1, or "scope" in v2.
> 
> You define your commands to apply to the current
> scope.  So:
> 
> (gdb) itfocus foo / scope foo
> (gdb) step
> 
> is the same as
> 
> (gdb) [foo] step  (v1)
> 
> or
> 
> (gdb) scope foo step  (v2)
> 
> IOW, you can think of prefix scope as a shorthand.  BTW, the v2 syntax is
> quite like TotalView's (they call theirs "dfocus", IIRC).

I think the semantics of this is confusing.
The command "scope foo" and "scope foo step" looks quite similar but has completely 
different semantics. If you compare again with a UNIX shell (which I think is a 
very good analogy and one that maps very well to the PCT concept)it would mean that 
you would write

> cd bar ls

instead of simply

> ls bar 

As you can see, I like the semantics of the Unix shell ;-)
The reason I use the shell as example is that our debugger shell is very much 
influenced by it and as I said, it maps very nicely. 

Both the UNIX shell and a debugger shell has a concept of a "current context". 
In the UNIX shell, it is the current working directory and in the debug shell it is 
the "current working set". 

In the Unix shell many commands operates on files and directories and in the debug 
shell it operates on cores, processes and threads.

We have even implemented shell things like ";" to execute more than one command like

cluster1/dsp0> step; print foo; go; print bar

will step the current core dsp0, then print the variable foo, then start execution 
and finally print the variable bar when we stop for some reason.

Another shell features we have is redirect of output, so that you can write things like

cluster1/dsp0> showregisters > my_regs.txt

The above command will store the contents of all registers on dsp0 in the file 
my_reg.txt. The nice thing about mimicking a real shell is that you have a lot of 
knowledge that can be directly transferred to the debug shell. 
If you know how to use a UNIX shell then many of the same concepts can be reused.

Cheers,
Tomas