From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18678 invoked by alias); 7 Oct 2010 23:03:46 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 18668 invoked by uid 22791); 7 Oct 2010 23:03:45 -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: Thu, 07 Oct 2010 23:03: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: <20101007225922.GA18085@redhat.com> References: <20100930182320.GA17475@redhat.com> <201010051930.38721.pedro@codesourcery.com> <20101006171953.GA28683@redhat.com> <201010061932.31628.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010061932.31628.pedro@codesourcery.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q4/txt/msg00007.txt.bz2 On 10/06, Pedro Alves wrote: > > On Wednesday 06 October 2010 18:19:53, Oleg Nesterov wrote: > > > > 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 ;) > > vCont was introduced because with only 'Hc', 's' and 'c', there's > no way to distinguish "step a thread and resume all others" vs "step > a thread and leave others stopped" (scheduler-locking, in gdb lingo). Hmm. Not sure I understand this... gdb could issue a series of Hc+c after s to do "step a thread and resume all others". But this doesn't matter. Obviously vCont is better and more handy. > Think of it as "undefined behavior". It could be made to > error out instead, if somebody cared. Not sure how you got gdb to > send gdbserver 's' or 'c' I did $ gdb `which gdb` `pidof gdb` to change its behaviour ;) > (well, unless you used > "set remote verbose-resume-packet off", or started gdbserver > with --disable-packet=vCont). Ah, I'd wish I knew this before. Damn, I recall I saw these disable_packet_xxx code in gdbserver sources, but forgot. > > 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. > > Yes. > > > > > 2. Say, $vCont;c:pPID.TID;s:p-1.-1 > > This would be effectively > > $vCont;c:pPID.TID;s > > > > > 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. > > All GDB currently sends is in gdb/remote.c:remote_vcont_resume. > All vCont packets GDB sends today have the actions ordered > from more specific to less specific Great. Pedro, thanks a lot. Oleg.