From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28720 invoked by alias); 3 Aug 2010 16:56:45 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 28704 invoked by uid 22791); 3 Aug 2010 16:56:42 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Tue, 03 Aug 2010 16:56:00 -0000 From: Oleg Nesterov To: Jan Kratochvil Cc: Roland McGrath , archer@sourceware.org, utrace-devel@redhat.com Subject: Re: Q: multiple inferiors, all-stop && vCont Message-ID: <20100803165359.GA11274@redhat.com> References: <20100803150656.GA8043@redhat.com> <20100803143004.GB2185@redhat.com> <20100803155521.GA3226@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100803155521.GA3226@host1.dyn.jankratochvil.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00086.txt.bz2 On 08/03, Jan Kratochvil wrote: > > On Tue, 03 Aug 2010 16:30:04 +0200, Oleg Nesterov wrote: > > However, I do not really understand how this can work reliably in the > > terms of remote protocol. Somehow this scheme relies on the fact that > > gdb will send another vCont;t:pTGID.-1 _once again_ after the previous > > vCont;t:pTGID.-1, and gdbserver can report the other threads via > > Stop/vStopped. OK, I hope this doesn't matter. > > attach_command_post_wait: > > /* At least the current thread is already stopped. */ > > /* In all-stop, by definition, all threads have to be already > stopped at this point. In non-stop, however, although the > selected thread is stopped, others may still be executing. > Be sure to explicitly stop all threads of the process. This > should have no effect on already stopped threads. */ > if (non_stop) > target_stop (pid_to_ptid (inferior->pid)); This just reflects the current situation with the current implementation. gdb already did vAttach;PID vCont;t:pPID.-1 I do not see anything in the _documentation_ which could explain that only the main thread can be stopped despite the fact "-1" means all threads. Once again, I already understand why gdb + gdbserver work this way, I meant remote protocol "in general". And in fact, I do not think your explanation is correct. Yes, this attach_command_post_wait() is called during attach. But even after that gdbserver reports only the main thread. This happens before qSymbol stage. Only when gdb issues yet _another_ vCont;t:pPID.-1 after that, gdbserver reports other threads, and this have nothing to do (I think) with attach_command_post_wait(). In fact, to me this all works _contrary_ to the comment above. Be sure to explicitly stop all threads of the process. This doesn't happen. But, it is very possible I missed something. Ang again, I think (I hope ;) we can forget this because the simple method works too. > > Yes. And please note that at least in-kernel gdbstub can not use > > libthread_db. But, I also hope that we can avoid it even if gdbstub > > runs in user-space ? > > As far as I understand it now in-kernel gdbserver does not need libthread_db > at all. The communication is based only on PID/TID anyway and on Linux we do > not need libthread_db to enumerate the TIDs of a PID. Yes, thanks. This is what I meant. I was afraid there are some other reason why we can't avoid libthread_db. > > Should I worry about this issue right now? > > The pthread_t / libthread_db stuff should be probably only the GDB client > problem. You will probably never face it. > > > And, I hope that "client side only using: libthread_db" means gdb, not > > gdbserver ? > > yes, I have meant it that way. Great, thanks. > > > why do you want from GDB to use specifically `vCont:c'? > > > > Because, first of all, I wanted to understand why gdb doesn't send > > vCont:c to me, but uses this command when it works with the real > > gdbserver. > > Anyway I see GDB uses `vCont;c' even with gdbstub so this problem is not > reproducible for me. > > => $vCont;c:p658.658 > <= $OK Yes. From another email from me: OK. After I read remote_vcont_resume()->remote_vcont_probe() path I understand why 'vCont;c;t' doesn't work. Contrary to what the documentation says it is all or nothing. Except 't' has the separate remote_state->support_vCont_t flag. Very strange. That is why gdbstub reports 'vCont;t;c;C;s;S' to 'vCont?', despite the fact it doesn't implement C/s/S yet. > > > But it is not yet stopped that time. > > > > Well. And how can I stop it? > > > > Once again, this all works in CLI mode. And this looks very natural > > What do you call CLI mode? We use only CLI mode so far all the time. The > other mode is MI (`gdb -i=mi'). Sorry for confusion, I do not know how to name it correctly... I can start gdb and then enter these commands by hand, this is what I called CLI (command line interface ;). And in this case everything works as I expected. Or I can put these command into the file FILE, and then do "$ gdb < FILE". In this case "attach" + "info registers" doesn't work. I didn't try "gdb -nx -ex ..." method yet. Otherwise, I always use remote mode. > This was this way in the sync/all-stop mode. In async/non-stop mode it is > intentionally asynchronous: > > attach_command: > if (target_can_async_p ()) > add_inferior_continuation (attach_command_continuation, a, > attach_command_continuation_free_args); > return; > > It may take some time before this inferior reports us back the stop and we may > want to debug other inferiors in the meantime. Yes, I see, > > Yes, yes, now I understand this. Once again, I was greatly confused > > because I didn't know that CLI mode makes the difference. Even if I > ^^^ local (=non-remote) probably no, please see above. And sorry for confusion again. So. To summarise, I never claimed this is a bug. OTOH, I think this difference can confuse a newbie like me. Yes, I do understand vAttach issues, but I thought that "attach" command should always hide these details. From the documentation: attach PROCESS-ID ... The first thing GDB does after arranging to debug the specified process is to stop it. You can examine and modify an attached process with all the GDB commands that are ordinarily available when you start processes with `run'. You can insert breakpoints; you can step and continue; you can modify storage. If you would rather the process continue running, you may use the `continue' command after attaching GDB to the process. Oleg.