From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30538 invoked by alias); 26 Feb 2002 17:29:56 -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 30398 invoked from network); 26 Feb 2002 17:29:49 -0000 Received: from unknown (HELO toenail.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 26 Feb 2002 17:29:49 -0000 Received: (from fche@localhost) by toenail.toronto.redhat.com (8.11.6/8.11.6) id g1QHTlX00940; Tue, 26 Feb 2002 12:29:47 -0500 X-Authentication-Warning: toenail.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Disable [eE] packets by default References: <3C79867F.3000906@cygnus.com> <3C798723.4D4B@redhat.com> Content-Type: text/plain; charset=US-ASCII From: fche@redhat.com (Frank Ch. Eigler) Date: Tue, 26 Feb 2002 09:29:00 -0000 In-Reply-To: <3C798723.4D4B@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 X-SW-Source: 2002-02/txt/msg00703.txt.bz2 msnyder wrote: > [...] I think this is the right thing to do. [...] OK. Can you or Andrew explain the reference to "threading code" in the patch comments? > > + /* Disable by default. The ``e'' packet has nasty interactions with > > + the threading code - it relies on global state. */ > > + remote_protocol_E.detect = CMD_AUTO_BOOLEAN_FALSE; > > + update_packet_config (&remote_protocol_E); > I would like to start discussing the right way to implement this. > For one thing, the current implementation has remote.c snatching > control away from infrun, and doing something completely > different from what infrun asked it to do. Right - it's interpreting the step=1 argument to remote_resume not just as "stepi" but as "step if you can, stepi if you can't". > I'd like to have the decision about whether to use step-over-range > made in infrun, not in the target layer. Yup. One less-pessimistic approach would be to clear step_range_end and step_range_start in proceed(), if the breakpoint_here_p() condition is true. This would mean that targets would have to do stepi loops when stepping off of a breakpoint, but otherwise could use step-over-range. - FChE