From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12235 invoked by alias); 28 Aug 2002 04:07:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12226 invoked from network); 28 Aug 2002 04:07:07 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 28 Aug 2002 04:07:07 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 14DC93E39; Wed, 28 Aug 2002 00:06:39 -0400 (EDT) Message-ID: <3D6C4C4E.4050409@ges.redhat.com> Date: Tue, 27 Aug 2002 21:07:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions References: <20020502022543.GA22594@nevyn.them.org> <20020816143040.GA22041@nevyn.them.org> <3D5D0F62.4010207@ges.redhat.com> <20020816145306.GA24002@nevyn.them.org> <3D65B53D.8050603@ges.redhat.com> <20020823124453.GA12257@nevyn.them.org> <3D6692AE.90601@ges.redhat.com> <20020823201549.GB26809@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00371.txt.bz2 > Sure. I suppose we should clean up the interface to resume, to prevent > all this confusion re-arising... which means figuring out our possible > behaviors, and whether they are even implementable on particular > targets. The spanner in the works here is simulators. They can't implement schedule-locking because their scheduler is hardwired. The best they can manage is step off current instruction. A simple version of this (PPC) (from memory) always implements step->schedule. If you step I the procesor. It complets one instruction on the current CPU and then schedules the next CPU for the next instruction. > On Linux the options for any given LWP (at the moment, that means for > any given thread) are step, run, stop. All combinations are available. > I think the _useful_ ones are: > > step one, stop others > step one, continue others > continue one, stop others > continue one, continue others > > And, of course: > stop one, stop others > :) > What is the absolute minimum needed? - step off breakpoint / thread-hop = using a sched lock single-step = using software single-step breakpoints and a sched lock continue (Note: this is where the existing interface really falls down -- step=0 so remote.c won't know to schedule-lock) - continue I think, after that, everything is an efficiency gain. Looking at the list: > step one, stop others Hardware single-step off of breakpoint. TPID, STEP, !OTH HcTID, s > step one, continue others Hardware single-step. TPID, STEP, OTH H???, s > continue one, stop others Schedule lock. Software single-step off breakpoint. TPID, !STEP, !OTH (wiered) HcTID, c > continue one, continue others Software single-step. General resume. TPID, !STEP, OTH Hc0, c > Something like: > resume (ptid, step, run_others, target_signal) > maybe? Does anyone think step_all is useful (I don't)? It is what a simulator might implement. So looking at the remote protocol. There in't a way of specifying TPID, STEP, OTH (your bug). Andrew > PS: > Some day letting the user be more precise (run these two threads) would > be nice. I envision a day in the distant future: > -> Continue thread 1 > -> Continue thread 2 > -> Wait for inferior status > <- All threads stopped, thread 1, SIGSEGV > or > -> Continue all threads > -> Wait for inferior status [maybe implicit in the all-threads > request] > <- Thread 1 stopped, shared lib breakpoint, all other threads running Try ``target remote-async''. > But let's not try to design to that quite yet :) :-)