On 10/28/2016 02:35 PM, Claudio Imbrenda wrote:
> On 27/10/16 13:40, Pedro Alves wrote:
>> I'm not a qemu gdbstub expert, but FYI, seeing this reminded me to push
>> to gdb's master a (getting old) gdb patch that clarifies how vCont actions
>> should be interpreted:
>>
>> https://sourceware.org/ml/gdb-patches/2016-02/msg00493.html
>>
>> It's already live at:
>>
>> https://sourceware.org/gdb/current/onlinedocs/gdb/Packets.html
>>
>> (The "already running" case is for non-stop mode, which qemu
>> probably doesn't support.)
>
> 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.
>
> e.g. vCont;c;s:1 will ignore the s:1 because the c was specified
> earlier and it matches all threads, and therefore it's the leftmost
> match? do I understand correctly?
Yes.
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.
(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
etc.
)
>
> 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
@samp{p@var{pid}.-1} form of the @var{thread-id}. An action with no
-@var{thread-id} is called the default action and matches all threads.
-Specifying multiple default actions is an error; specifying no actions
-is also an error.
+@var{thread-id} matches all threads. Specifying no actions is an
+error.
I.e., go from this:
~~~
For each inferior thread, the leftmost action with a matching
thread-id is applied. Threads that don’t match any action remain in
their current state. Thread IDs are specified using the syntax
described in thread-id syntax. If multiprocess extensions (see
multiprocess extensions) are supported, actions can be specified to
match all threads in a process by using the ‘ppid.-1’ form of the
thread-id. An action with no thread-id is called the default action
and matches all threads. Specifying multiple default actions is an
error; specifying no actions is also an error.
~~~
To this:
~~~
For each inferior thread, the leftmost action with a matching
thread-id is applied. Threads that don’t match any action remain in
their current state. Thread IDs are specified using the syntax
described in thread-id syntax. If multiprocess extensions (see
multiprocess extensions) are supported, actions can be specified to
match all threads in a process by using the ‘ppid.-1’ form of the
thread-id. An action with no thread-id matches all threads. Specifying
no actions is an error.
~~~
Would that help ?
Thanks,
Pedro Alves
