From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24748 invoked by alias); 26 Jul 2010 14:30:40 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 24737 invoked by uid 22791); 26 Jul 2010 14:30:38 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RDNS_NONE,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Date: Mon, 26 Jul 2010 14:30:00 -0000 From: Oleg Nesterov To: Roland McGrath Cc: archer@sourceware.org Subject: Re: Q: multiple inferiors, all-stop && vCont Message-ID: <20100726142759.GA17171@redhat.com> References: <20100716205147.GA26313@redhat.com> <20100721170400.GA30978@redhat.com> <20100721204203.D040C400B6@magilla.sf.frob.com> <20100723173134.GA29717@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100723173134.GA29717@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00060.txt.bz2 On 07/23, Oleg Nesterov wrote: > > On 07/21, Roland McGrath wrote: > > > > Well, actual practice of rarely-used features, anyway. > > Multi-process is newfangled and apparently quite unreliable. > > Single-process, multi-thread is what is used a lot. > > OK. I'll try to send something more or less working on Monday. No, I need more time. Hopefully one more day, may be two, I am not sure. The problem is not the coding itself. The problem is that almost every step needs a lot of experiments with gdb/gdbserver/ugdb. 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. 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. 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. 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. 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?'. The are some other issues with vCont which I don't understand... And I'd say gdb crashes too often. So. I am working. Everything goes slower than I expected. When I have the code which more or less works - I'll send it. I decided to take a bit different approach, we will see if it makes sense in the longer term. Oleg.