From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2483 invoked by alias); 3 Aug 2010 14:32:44 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 2459 invoked by uid 22791); 3 Aug 2010 14:32:40 -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 14:32:00 -0000 From: Oleg Nesterov To: Jan Kratochvil Cc: Roland McGrath , archer@sourceware.org Subject: Re: Q: multiple inferiors, all-stop && vCont Message-ID: <20100803143004.GB2185@redhat.com> References: <20100716205147.GA26313@redhat.com> <20100721170400.GA30978@redhat.com> <20100721204203.D040C400B6@magilla.sf.frob.com> <20100723173134.GA29717@redhat.com> <20100726142759.GA17171@redhat.com> <20100803123940.GA16669@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100803123940.GA16669@host1.dyn.jankratochvil.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00083.txt.bz2 On 08/03, Jan Kratochvil wrote: > > 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? Heh. Funny that, I just sent another email which explains how I was confused (in reply to my first "Q: %Stop && gdb crash" message). > 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 Yes, this is OK. And this is how this all works when I enter the commands via CLI (probably -ex works too). > Are you aware of the comment before remote_get_pending_stop_replies()? Well, I read it before, but I was never able to parse it up to the end ;) > > 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. Yes, I know. > Immediately at the moment of vAttach GDB may not be able to answer those > questions so it is delayed a bit. Yes, I have to take my "gdbserver is just wrong" back. 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. > > 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<= $ 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 ? > 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) Cough. This is black magic to me ;) I probably understand what pthread_t is, but I do not know how/if this is important for gdb. Should I worry about this issue right now? And, I hope that "client side only using: libthread_db" means gdb, not gdbserver ? > > 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, Yes, I know. > 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. Also, I am trying to identify the "essential" commands subset. Afaics, vCont:c is preferred, and gdb never uses 'c' if it knows it can use 'vCont:c'. And. How could I verify that I handle vCont:c correctly if I wasn't able to provoke gdb to send it? Oleg.