From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9120 invoked by alias); 10 Oct 2003 01:28:20 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9111 invoked from network); 10 Oct 2003 01:28:16 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 10 Oct 2003 01:28:16 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A7m4i-0007SH-Vx for ; Thu, 09 Oct 2003 21:28:12 -0400 Date: Fri, 10 Oct 2003 01:28:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA] New threads test Message-ID: <20031010012812.GA28600@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030930192158.GA5615@nevyn.them.org> <3F7B1ED7.4040403@redhat.com> <20031001185230.GA25467@nevyn.them.org> <20031009141057.GB29621@nevyn.them.org> <3F85B9DC.4020804@redhat.com> <20031009194939.GA20253@nevyn.them.org> <3F85F7CD.6090809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F85F7CD.6090809@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00343.txt.bz2 On Thu, Oct 09, 2003 at 05:05:33PM -0700, Michael Snyder wrote: > Daniel Jacobowitz wrote: > >On Thu, Oct 09, 2003 at 12:41:16PM -0700, Michael Snyder wrote: > > > >>Daniel Jacobowitz wrote: > >> > >>>On Wed, Oct 01, 2003 at 02:52:30PM -0400, Daniel Jacobowitz wrote: > >>> > >>> > >>>>On Wed, Oct 01, 2003 at 11:37:11AM -0700, Michael Snyder wrote: > >>>> > >>>> > >>>>>Daniel Jacobowitz wrote: > >>>>> > >>>>> > >>>>>>This is a test for the remote protocol issue I'm solving with vCont. > >>>>>>It > >>>>>>also shows up in schedlock, but the simpler test makes it much clearer > >>>>>>what's going wrong. OK? > >>>>>> > >>>>> > >>>>>Umm... what is going wrong? What are you testing for here? > >>>> > >>>>+# It tests that the correct thread is single-stepped. > >>>> > >>>>More intelligibly: when gdbserver is told to single-step one thread > >>>>(without holding all others schedlocked), it assumes we mean the first > >>>>thread. Which might not be the _right_ thread. > >> > >>Hmmm... it should assume we mean the _current_ thread > >>(ie. the one that had a stop event). The remote protocol > >>should cover this (and did, last I checked). > > > > > >I could have changed gdbserver to default to that, in fact I thought I > >had (but I hadn't). But it still breaks down if the user switches > >threads explicitly - > > Hmmm, that's what target_prepare_to_proceed is supposed to handle. > Err... was. What happened to it? I missed this discussion, I guess. It's still there. It turned out that all of the architecture specific versions could be replaced by a generic one. prepare_to_proceed is part of the solution, yes - the reason that it was changed was because I also ran into that when working on the same problem. But the problem is that the remote protocol wasn't rich enough to describe what we wanted to do. Particularly the difference between: step thread 3 step thread 3 and let all other threads run We got instead: step thread 3 step some thread and let all other threads run > >see vCont, which this is testing. > > Can you refer me to the threads on vcont? I've been seeing > references to it, but haven't found the origin or the definition. The origin is hard to follow in the list archives, since the conversation took six or seven months. You can find the final definition at: http://sources.redhat.com/ml/gdb/2003-10/msg00020.html and some earlier discussion at: http://sources.redhat.com/ml/gdb/2003-09/msg00210.html and http://sources.redhat.com/ml/gdb-patches/2003-09/msg00624.html -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer