Re: BUG: gdb notification packets (Was: gdbstub initial code, v12)
On Thursday 07 October 2010 23:59:22, Oleg Nesterov wrote: 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. Not in all-stop mode. GDB can not send any other command to the stub until the stub returns a stop reply to the first 's'. Remember, there's no vStopped+notifications in the all-stop mode protocol. -- Pedro Alves
Re: BUG: gdb notification packets (Was: gdbstub initial code, v12)
On 10/05, Pedro Alves wrote: (reordered) On Tuesday 05 October 2010 18:27:29, Oleg Nesterov wrote: So, I strongly believe gdb is buggy and should be fixed. Fix your stub to implement vCont;s/c(/S/C). First of all, I confirm that when I added the (incomplete right now) support for vCont;s the problem goes away, gdb never forgets to send the necessary vStopped to consume all stop-reply packets. Thanks Pedro. The more or less typical transcript is: [... snip ...] = s This is already wrong. The stub must support @samp{vCont} if it reports support for multiprocess extensions (@pxref{multiprocess extensions}). 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 ;) Currently ugdb only supports vCont;t because otherwise there is obviously no way to stop all threads. 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' ? 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. And what should be replied back to '$s', nothing? Very strange. But seems to work... And yes, this explains the hang, gdb thinks that this OK is connected to vStopped. 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'. So. I still belive that something is wrong with gdb/gdbserever but I don't care. 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. 2. Say, $vCont;c:pPID.TID;s:p-1.-1 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. Thanks, Oleg.
Re: BUG: gdb notification packets (Was: gdbstub initial code, v12)
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 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). 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
Re: BUG: gdb notification packets (Was: gdbstub initial code, v12)
On Tuesday 05 October 2010 19:30:38, Pedro Alves wrote: Now, given this, I won't be surprised if you're seeing races with -s, -OK, -vCont sequences, as GDB may well be thinking that the OK is a reply to the vCont. I meant -s, -OK, -vStopped sequences. -- Pedro Alves