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

[Oleg Nesterov <oleg@redhat.com>]

On 10/06, Pedro Alves wrote:
>
> On Wednesday 06 October 2010 18:19:53, Oleg Nesterov wrote:
> >
> > 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).

Hmm. Not sure I understand this... gdb could issue a series of Hc+c
after s to do "step a thread and resume all others".

But this doesn't matter. Obviously vCont is better and more handy.

> 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'

I did $ gdb `which gdb` `pidof gdb` to change its behaviour ;)

> (well, unless you used
> "set remote verbose-resume-packet off", or started gdbserver
> with --disable-packet=vCont).

Ah, I'd wish I knew this before. Damn, I recall I saw these
disable_packet_xxx code in gdbserver sources, but forgot.

> > 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

Great.

Pedro, thanks a lot.

Oleg.