Re: BUG: gdb && notification packets (Was: gdbstub initial code, v12)

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 06 October 2010 18:19:53, Oleg Nesterov wrote:
> On 10/05, Pedro Alves wrote:
> > "The stub must support @samp{vCont} if it reports support for
> > multiprocess extensions (@pxref{multiprocess extensions})."
> 
> Cough. Previously I was told here (on archer@sourceware.org) that
> Hc + s/c is enough and I shouldn't worry about vCont;s/c ;)

vCont was introduced because with only 'Hc', 's' and 'c', there's
no way to distinguish "step a thread and resume all others" vs "step
a thread and leave others stopped" (scheduler-locking, in gdb lingo).
This was added way before non-stop was added, back in 2002/2003,
I believe.  vCont;t was added much later, when non-stop was
introduced.

> > The stub must also support vCont for non-stop, though I'll give you
> > that it doesn't appear to be mentioned in the manual,
> 
> Yes, the manual doesn't explain this. Quite contrary, the decsription
> of 'vCont?' definitely looks as if the stub is not obliged to implement
> all vCont commands.
> 
> And, if the stub must support vCont for non-stop, then why gdb
> doesn't complain after 'vCont?' but falls back to '$s' ?

Because nobody took the trouble to made it complain.  As I said,
I'll give you that gdb could be noisier about that...

> > Look at remote.c:remote_resume, and you'll see that gdb does not
> > wait for the "OK" after 'c'/'s'/'S'/'C' in non-stop mode.
> 
> Then gdbserver should be fixed? It does send "OK" in response to '$s',
> that is why ugdb does this.

Think of it as "undefined behavior".  It could be made to
error out instead, if somebody cared.  Not sure how you got gdb to
send gdbserver 's' or 'c' (well, unless you used
"set remote verbose-resume-packet off", or started gdbserver
with --disable-packet=vCont).

> Again, the documentation is very confusing. Looking at
> remote_resume()->remote_vcont_resume()->getpkt() I think that
> vCont;s needs "OK". Looking at "D.3 Stop Reply Packets" in
> gdb.info I do not see any difference between `s' and `vCont'.

Yeah.  It's the problem that those that are very familiar with
the thing get to write docs for it, so may have missed spelling
out things that were obvious to them.

It goes without saying, but ... patches to improve the docs are
always welcome.

> In any case ugdb should fully support vCont, hopefully I'll finish
> this tomorrow. Could you answer a couple of questions?
> 
> 1. Say, $vCont;s or $vCont;s:p-1.-1
> 
>    I assume, this should ignore the running threads, correct?
>    IOW, iiuc this 's' applies to all threads which we already
>    reported as stopped.

Yes.

> 
> 2. Say, $vCont;c:pPID.TID;s:p-1.-1

This would be effectively

    $vCont;c:pPID.TID;s

> 
>    Can I assume that gdb can never send this request as
> 
>    	$vCont;s:p-1.-1;c:pPID.TID ?
> 
>    If yes, then the implementation will be much simpler, I can
>    add something like gencounters to ugdb_thread/process. Otherwise
>    this needs more complications to figure out what should be done
>    with each tracee.

All GDB currently sends is in gdb/remote.c:remote_vcont_resume.
All vCont packets GDB sends today have the actions ordered
from more specific to less specific --- the most complicated
is something like "vCont;s:pPID.TID;c" (step PID.TID, continue
all others).  It will probably make sense to maintain that
ordering, if we ever make a single vCont contain more
actions.

-- 
Pedro Alves