From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15129 invoked by alias); 21 Jul 2010 17:06:22 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 14953 invoked by uid 22791); 21 Jul 2010 17:06:19 -0000 X-SWARE-Spam-Status: No, hits=-6.7 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: Wed, 21 Jul 2010 17:06:00 -0000 From: Oleg Nesterov To: archer@sourceware.org Subject: Q: multiple inferiors, all-stop && vCont Message-ID: <20100721170400.GA30978@redhat.com> References: <20100716205147.GA26313@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100716205147.GA26313@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00057.txt.bz2 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 /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.