Re: [Qemu-devel] [PATCH v2 2/2] gdbstub: Fix vCont behaviour

[Claudio Imbrenda]

On 28/10/16 16:01, Pedro Alves wrote:
>> From the new specifications I seem to understand that if I specify a
>> default as first action, then no further actions will be considered,
>> since it matches all threads?
> 
> Right.

ok, that's the way I understand the new specs, which is not how I had
understood the old specs (hence my questions), so I think your
documentation patch was really needed.

> Note that GDB never ever sent a vCont like that.  It's always put
> the default action last.  So in practice, it doesn't change
> any behavior.  OTOH, stubs can be simpler, given there's no need to
> special-case the default action.

ok, I admit I never looked deeply into what GDB sends :)

> (Also, with this definition we can safely break a big vCont packet
> in multiple smaller ones, in non-stop mode:
> 
>  vCont;s:1;c == vCont;s:1 + vCont;c
>  vCont;c;s:1 == vCont;c + vCont;s:1
>  vCont;s:1;s:2;s:3;s:3;s:4;...s:N;c == vCont;s:1;s:2;s:3 + vCont;s:4;...s:N;c

that makes sense, although I never looked into it since Qemu doesn't
support non-stop mode

>> Or does the default only match any thread without an explicit match?
>> (which is how I interpreted the old spec)
> 
> Maybe I should just remove all mentions of a "default" from the text?

[..]

> Like:
> 
> diff --git c/gdb/doc/gdb.texinfo w/gdb/doc/gdb.texinfo
> index d636a16..df548dc 100644
> --- c/gdb/doc/gdb.texinfo
> +++ w/gdb/doc/gdb.texinfo
> @@ -35538,9 +35538,8 @@ syntax described in @ref{thread-id syntax}.  If 
> multiprocess
>  extensions (@pxref{multiprocess extensions}) are supported, actions
>  can be specified to match all threads in a process by using the
>  @address@hidden form of the @var{thread-id}.  An action with no
> address@hidden is called the default action and matches all threads.
> -Specifying multiple default actions is an error; specifying no actions
> -is also an error.
> address@hidden matches all threads.  Specifying no actions is an
> +error.

> Would that help ?

that makes it even more clear (and simple).
On the other hand, now expressing more than one default is not
considered an error any longer (although the extra defaults serve no
purpose); in the end it wouldn't break backwards compatibility, so why not.

Basically a "default" e.g. "s" is the same as specifying "s:-1". This
does make the implementation of the stub easier.


thanks a lot for your prompt and detailed reply!