From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2263 invoked by alias); 18 Feb 2003 23:43:26 -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 2254 invoked from network); 18 Feb 2003 23:43:26 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 23:43:26 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 82E062D37; Tue, 18 Feb 2003 18:48:13 -0500 (EST) Message-ID: <3E52C63C.6050405@redhat.com> Date: Tue, 18 Feb 2003 23:43:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Is stub support for the 's' packet optional or required? References: <20030218020408.EE11C3CF2@localhost.redhat.com> <1030218162957.ZM3642@localhost.localdomain> <20030218165140.GA17229@nevyn.them.org> <3E52A0A7.5020104@redhat.com> <1030218214337.ZM4871@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00327.txt.bz2 > On Feb 18, 4:07pm, Andrew Cagney wrote: > > >> # FIXME/cagney/2001-01-18: This should be split in two. A target method >> that indicates if the target needs software single step. An ISA method >> to implement it. > > > This one puzzles me. How can gdb find out if a target (e.g. remote stub) > can single step without first attempting the operation? Like I said, take it with a grain of salt. The key thing here is that it is the target, and not the architecture, that is consulted first. It could be handled internally by target resume, or a new method target_singlestep_p(). For remote, target_singlestep_p() might initially return false but then, when it realises the mistake, return true. WFI would recover from this foo-bar since the first wait would just return TARGET_WAITKIND_SPURIOUS (or perhaphs TARGET_WAITKIND_LOOK_TRY_CONTINUE :-). >> # FIXME/cagney/2001-01-18: This should be replaced with something that >> inserts breakpoints using the breakpoint system instead of blatting >> memory directly (as with rs6000). > > > I agree with this and am looking into doing it. Again it's theory. I think it is better if WFI is directly aware of the location of the single-step breakpoints. Per your comments each target_resume() can also handle this directly (I think, long ago stu grossman suggested something like that?). For remote.c though, this may not be possible. After resuming the target it needs to return to the event loop. Then, when a target event (eg "" or "T...") arrives, it processes it realizing that the "s" packet was ignored. This also means that each generic target (proc, ptrace, remote) needs to be separatly modified. >> # FIXME/cagney/2001-01-18: The logic is backwards. It should be asking >> if the target can single step. If not, then implement single step using >> breakpoints. > > > It seems to me that this could be rolled into the first comment, above. Yes. >> (All taken with a grain of salt.) > > > After (re)reading these comments, I came up with a different strategy > (which I'm presently rethinking). Instead of asking the target if > it can single step, it might be better to push the SOFTWARE_SINGLE_STEP > invocation down to the bottom-most target resume() (i.e, child_resume() > for many natives). At the moment, it's in resume() in infrun.c. > (There is also a call which removes the breakpoints, but, presumably > if we get things using the breakpoint system, this can be replaced > with something better.) Andrew