From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21598 invoked by alias); 3 Aug 2010 12:39:50 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 21584 invoked by uid 22791); 3 Aug 2010 12:39:49 -0000 X-SWARE-Spam-Status: No, hits=-6.0 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 12:39:00 -0000 From: Jan Kratochvil To: Oleg Nesterov Cc: Roland McGrath , archer@sourceware.org Subject: Re: Q: multiple inferiors, all-stop && vCont Message-ID: <20100803123940.GA16669@host1.dyn.jankratochvil.net> References: <20100716205147.GA26313@redhat.com> <20100721170400.GA30978@redhat.com> <20100721204203.D040C400B6@magilla.sf.frob.com> <20100723173134.GA29717@redhat.com> <20100726142759.GA17171@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100726142759.GA17171@redhat.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-SW-Source: 2010-q3/txt/msg00079.txt.bz2 On Mon, 26 Jul 2010 16:27:59 +0200, Oleg Nesterov wrote: > For example, I spent several hours trying to understand why gdb > ignores '%Stop:' notification and never sends '$vStopped', but > it does send vStopped to the real gdbserver with the same batch > file. The reason was partly my misunderstanding, but also another > bug in gdb and the timing issues. Which bug in gdb do you mean? I do not have the problem reproducible, the logs look OK. => $vCont;t:p5b84.-1 <= $OK <= %Stop:T00thread:p5b84.5b84; => $vStopped <= $T00thread:p5b84.5b87; => $vStopped <= $OK Are you aware of the comment before remote_get_pending_stop_replies()? > Or vAttach in the multithreaded case. I'd say that gdbserver is just > wrong here, even if this works in practice. The first qfThreadInfo > after vAttach reports only the main thread. Yes... OK: getpkt ("qXfer:threads:read::0,fff"); [no ack sent] putpkt ("$l #de"); [noack mode] > After the first > vCont;t:PID.-1 only the main thread is reported again. Somehow it > provokes gdb to send more 'vCont;t:PID.-1's packets, only then it > reports the new threads via Stop/vStopped. Only after GDB issues: ->server: getpkt ("qSymbol::"); [no ack sent] [...] <-server: putpkt ("$qSymbol:5f7468726561645f64625f6c6973745f745f6e657874#a0"); [noack mode] = _thread_db_list_t_next ->server: getpkt ("qSymbol:7f4c9a0ab0bc:5f7468726561645f64625f6c6973745f745f6e657874"); [no ack sent] = _thread_db_list_t_next gdbserver can ask GDB for some symbols the gdbserver needs to provide to libthread_db to be able to find out all the inferior threads using libthread_db calling back gdbserver's ps_pglobal_lookup. `qSymbol::' Notify the target that GDB is prepared to serve symbol lookup requests. Accept requests from the target for the values of symbols. Immediately at the moment of vAttach GDB may not be able to answer those questions so it is delayed a bit. > At first I tried to mimic this behaviour, I was already totally > confused because I also had other problems with gdb - it constantly > crashed. But finally I have found that the simple approach seems to > work too. Yes, I see: gdb=> $vAttach;5bb7 gdb<= $OK gdb=> $qfThreadInfo gdb<= $mp5bb7.5bb7,p5bb7.5bba gdb=> $qsThreadInfo gdb<= $l [...] gdb=> $qSymbol:: gdb<= $ Even FSF gdbserver does not seem to use/provide pthread_t identifiers: 2 Thread 23487.23490 0x00007fb25c983a6d in nanosleep () at ../sysdeps/unix/syscall-template.S:82 * 1 Thread 23487.23487 0x00007fb25cc63fbd in pthread_join (threadid=140404033701648, thread_return=0x0) at pthread_join.c:89 as provided by local linux-nat.c / linux-thread-db.c. 2 Thread 0x7ffff7842710 (LWP 23503) 0x00007ffff78e9a6d in nanosleep () at ../sysdeps/unix/syscall-template.S:82 * 1 Thread 0x7ffff7ff3700 (LWP 23500) 0x00007ffff7bc9fbd in pthread_join (threadid=140737346021136, thread_return=0x0) at pthread_join.c:89 The LWP -> thread_t conversion could be done later from the client side only using: libthread_db (td_ta_map_lwp2thr(), td_thr_get_info(), typeof (td_thrinfo_t->ti_tid) = thread_t) > Right now I am trying to understand why gdb doesn't use 'vCont:c' > but sends 'c' instead. And yes, I report 'vCont;c;t' to 'vCont?'. GDB can use both, why do you want from GDB to use specifically `vCont:c'? `c' uses the inferior-kind specified by `Hc' (server'c cont_thread). Thanks, Jan