From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7513 invoked by alias); 27 Feb 2002 01:31:36 -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 7426 invoked from network); 27 Feb 2002 01:31:22 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 27 Feb 2002 01:31:22 -0000 Received: from redhat.com (notinuse.cygnus.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA03252; Tue, 26 Feb 2002 17:31:19 -0800 (PST) Message-ID: <3C7C34DD.4773D940@redhat.com> Date: Tue, 26 Feb 2002 17:31:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Disable [eE] packets by default References: <3C79867F.3000906@cygnus.com> <3C798723.4D4B@redhat.com> <3C7C3525.2070209@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00707.txt.bz2 Andrew Cagney wrote: > > > Andrew Cagney wrote: > > > >> > >> Hello, > >> > >> This is a followup to the current discussion regarding the [Ee] packets. > >> It disables them by default. > >> > >> While it is a brutal solution to a problem, it is also 6 days before 5.2 > >> branches. It also clears the slate for another attempt at this. > >> > >> Thoughts? > > > > > > I think this is the right thing to do. Previously we had > > no way to test the 'e' packet. Now that we do have, it is > > seen to be buggy. This is like an unreliable optimization. > > You can give the user the opportunity to use it if he chooses, > > but you don't turn it on by default. > > It is in. We're now free to figure out how to really make this work :-) > > > 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. I'd like to have > > the decision about whether to use step-over-range made in > > infrun, not in the target layer. > > Yes, definitly. I suspect step-out-of-range is a special case of step. > I think the decision to try to use both should be made by infrun.c. I'm picturing a "to_step_over_range" target vector, and the decision about whether or not to use it would be made in infrun/resume, right about the same place where it decides whether to use step or continue.