This is the mail archive of the
mailing list for the Archer project.
Re: BUG: gdb && notification packets (Was: gdbstub initial code,v12)
On 10/06, Pedro Alves wrote:
> On Wednesday 06 October 2010 18:19:53, Oleg Nesterov wrote:
> > Cough. Previously I was told here (on firstname.lastname@example.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.
> > 2. Say, $vCont;c:pPID.TID;s:p-1.-1
> This would be effectively
> > 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
Pedro, thanks a lot.