From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1283 invoked by alias); 6 Oct 2010 17:23:56 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 1258 invoked by uid 22791); 6 Oct 2010 17:23:53 -0000 X-SWARE-Spam-Status: No, hits=-6.4 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, 06 Oct 2010 17:23:00 -0000 From: Oleg Nesterov To: Pedro Alves Cc: archer@sourceware.org, utrace-devel@redhat.com Subject: Re: BUG: gdb && notification packets (Was: gdbstub initial code, v12) Message-ID: <20101006171953.GA28683@redhat.com> References: <20100930182320.GA17475@redhat.com> <20101004181053.GA30217@redhat.com> <20101005172729.GA27882@redhat.com> <201010051930.38721.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010051930.38721.pedro@codesourcery.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q4/txt/msg00005.txt.bz2 On 10/05, Pedro Alves wrote: > (reordered) > On Tuesday 05 October 2010 18:27:29, Oleg Nesterov wrote: > > > So, I strongly believe gdb is buggy and should be fixed. > > Fix your stub to implement vCont;s/c(/S/C). First of all, I confirm that when I added the (incomplete right now) support for vCont;s the problem goes away, gdb never forgets to send the necessary vStopped to consume all stop-reply packets. Thanks Pedro. > > The more or less "typical" transcript is: > > > > [... snip ...] > > => s > > This is already wrong. > > "The stub must support @samp{vCont} if it reports support for > multiprocess extensions (@pxref{multiprocess extensions})." Cough. Previously I was told here (on archer@sourceware.org) that Hc + s/c is enough and I shouldn't worry about vCont;s/c ;) Currently ugdb only supports vCont;t because otherwise there is obviously no way to stop all threads. > The stub must also support vCont for non-stop, though I'll give you > that it doesn't appear to be mentioned in the manual, Yes, the manual doesn't explain this. Quite contrary, the decsription of 'vCont?' definitely looks as if the stub is not obliged to implement all vCont commands. And, if the stub must support vCont for non-stop, then why gdb doesn't complain after 'vCont?' but falls back to '$s' ? > Look at remote.c:remote_resume, and you'll see that gdb does not > wait for the "OK" after 'c'/'s'/'S'/'C' in non-stop mode. Then gdbserver should be fixed? It does send "OK" in response to '$s', that is why ugdb does this. And what should be replied back to '$s', nothing? Very strange. But seems to work... And yes, this explains the hang, gdb thinks that this "OK" is connected to vStopped. Again, the documentation is very confusing. Looking at remote_resume()->remote_vcont_resume()->getpkt() I think that vCont;s needs "OK". Looking at "D.3 Stop Reply Packets" in gdb.info I do not see any difference between `s' and `vCont'. So. I still belive that something is wrong with gdb/gdbserever but I don't care. In any case ugdb should fully support vCont, hopefully I'll finish this tomorrow. Could you answer a couple of questions? 1. Say, $vCont;s or $vCont;s:p-1.-1 I assume, this should ignore the running threads, correct? IOW, iiuc this 's' applies to all threads which we already reported as stopped. 2. Say, $vCont;c:pPID.TID;s:p-1.-1 Can I assume that gdb can never send this request as $vCont;s:p-1.-1;c:pPID.TID ? If yes, then the implementation will be much simpler, I can add something like gencounters to ugdb_thread/process. Otherwise this needs more complications to figure out what should be done with each tracee. Thanks, Oleg.