Re: Q: multiple inferiors, all-stop && vCont

[Oleg Nesterov <oleg@redhat.com>]

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.