Q: multiple inferiors, all-stop && vCont

[Oleg Nesterov <oleg@redhat.com>]

Probably the last question before I'll try to add the threading
support.

I am trying to undestand what ugdb should know about the multiple
inferiors. Looks like, I shouldn't worry at all. They do not exist
from gdbserver's pov. It should handle the multiple attach/detach,
of course, but that is all. Say, qsThreadInfo should list all
attached threads in random order. IOW, there is no any command
which can refer to any particular inferior somehow, explicitly or
implicitly. Only THREAD-ID can matter.

Correct?

-------------------------------------------------------------------------------
But there is one oddity I can't understand in all-stop mode.

	(gdb) info inferiors
	  Num  Description       Executable
	* 3    process 22988     /bin/sleep
	  2    process 22823     /bin/sleep
	  1    process 22822     /bin/sleep
	(gdb) info threads
	* 3 Thread 22988.22988  0x000000375faa6390 in __nanosleep_nocancel () from /lib64/libc.so.6
	  2 Thread 22823.22823  0x000000375faa6390 in __nanosleep_nocancel () from /lib64/libc.so.6
	  1 Thread 22822.22822  0x000000375faa6390 in __nanosleep_nocancel () from /lib64/libc.so.6
	(gdb) c
	Continuing.

The last 'c' correctly resumes all processes/threads. But, gdb
sends the single vCont packet, and this packet is

	vCont;c:p59cc.-1

iow, it asks to resume only the 3rd 22988 process.

Does this mean that gdbserver should always ignore the THREAD-ID part
of this command in all-stop mode?

Oh. grep, grep, grep. Looks like this is true, but the code is nontrivial.
Not sure I understand it correctly.

It seems to me, handle_v_cont() first resumes the process it was
asked explicitly, then it does mywait(minus_one_ptid) and eventually
this ptid is passed to linux_resume() to wake up other threads.

I must admit, this looks a bit strange. Why gdb doesn't send
"vCont;c:-1.-1" which looks obviously more logical ?

I am afraid I missed something I should know here, I'll appreciate
any info.


-------------------------------------------------------------------
Well. And perhaps there is another bug....

If I sent SIGCONT to one of the processes, then gdbserver reports
T13 and stops all 3 processes, this looks correct.

gdb looks good too:

	Program received signal SIGCONT, Continued.
	[Switching to Thread 22822.22822]

But, the next continue

	(gdb) c
	Continuing.

resumes only one process, that one who recieved the signal. Other
processes are not resumed. Hmm, and CTRL-C does not work after that.

I can't understand this. Bug? Or something I should learn?

Just in case, I tried other sig_kernel_ignore() signals instead of
SIGCONT, the same.

-------------------------------------------------------------------
Let's play with SIGKILL.

	(gdb) info inferiors
	  Num  Description       Executable
	  3    process 29449     /bin/sleep
	  2    process 28409     /bin/sleep
	* 1    process 28408     /bin/sleep
	(gdb) c
	Continuing.

kill -9 29449. gdbserver correctly reports "X9;process:7309", gdb
informs the user:

	Program terminated with signal SIGKILL, Killed.
	The program no longer exists.
	(gdb) info inferiors
	  Num  Description       Executable
	* 3    <null>            /bin/sleep
	  2    process 28409     /bin/sleep
	  1    process 28408     /bin/sleep
	(gdb) info threads
	  2 Thread 28409.28409  0x00000000000000b0 in ?? ()
	  1 Thread 28408.28408  0x3030303030303030 in ?? ()

	No selected thread.  See `help thread'.
	(gdb)

But. In this case gdbserver does not stop other inferiors/threads,
there are running.

Isn't this wrong? This is all-stop mode. Or I misread the docs, this
is very possible.

But afaics, this can't be right.

	(gdb) inferior 1
	[Switching to inferior 1 [process 28408] (/bin/sleep)]
	[Switching to thread 1 (Thread 28408.28408)] 
	#0  0x3030303030303030 in ?? ()

Indeed, gdb blindly sends m/g requests and gets E01 or the bogus
register data from gdbserver.

	(gdb) c
	Continuing.
	^C
	Program received signal SIGINT, Interrupt.
	0x3030303030303030 in ?? ()

this finally stops 2 other processes,

	(gdb) c
	Continuing.

	Program received signal SIGSEGV, Segmentation fault.
	0x3030303030303030 in ?? ()
	(gdb)

Hmm. Yes, /bin/sleep is killed by SIGSEGV. Nice. Well, starting from
here nothing really works.

----------------------------------------------------------------------
So. Reference to actual practice doesn't help, I suspect it is buggy.

From gdb.info

	`vCont[;ACTION[:THREAD-ID]]...'
	     Resume the inferior, specifying different actions for each thread.
	     If an action is specified with no THREAD-ID, then it is applied to
	     any threads that don't have a specific action specified; if no
	     default action is specified then other threads should remain
	     stopped in all-stop mode

I can't really parse this... but let's look at gdb's vCont packet again,

	vCont;c:p59cc.-1

To me, it looks as "no default action is specified". Doesn't this mean
gdbserver should not have resumed other processes?

Confused.

Oleg.