On 10/06, Pedro Alves wrote: > > On Wednesday 06 October 2010 18:19:53, Oleg Nesterov wrote: > > > > Cough. Previously I was told here (on arc...@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.
