From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24368 invoked by alias); 16 Aug 2002 21:40:22 -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 24291 invoked from network); 16 Aug 2002 21:40:20 -0000 Received: from unknown (HELO rennsau.regent.e-technik.tu-muenchen.de) (129.187.231.63) by sources.redhat.com with SMTP; 16 Aug 2002 21:40:20 -0000 Received: from reisser.regent.e-technik.tu-muenchen.de (reisser.regent.e-technik.tu-muenchen.de [129.187.231.143]) by rennsau.regent.e-technik.tu-muenchen.de (8.8.8/8.6.9) with ESMTP id XAA20385 ; Fri, 16 Aug 2002 23:40:19 +0200 (MET DST) From: "Peter.Schauer" Received: (pes@localhost) by reisser.regent.e-technik.tu-muenchen.de (8.8.8/8.6.9) id XAA16421 ; Fri, 16 Aug 2002 23:40:17 +0200 (MET DST) Message-Id: <200208162140.XAA16421@reisser.regent.e-technik.tu-muenchen.de> Subject: Re: [RFA] enable software single step on alpha-osf To: kevinb@redhat.com (Kevin Buettner) Date: Fri, 16 Aug 2002 14:40:00 -0000 Cc: drow@mvista.com, ac131313@ges.redhat.com, brobecker@gnat.com, gdb-patches@sources.redhat.com In-Reply-To: <1020816194018.ZM31084@localhost.localdomain>; from "Kevin Buettner" at Aug 16, 102 9:46 pm X-SW-Source: 2002-08/txt/msg00460.txt.bz2 Sigh. http://sources.redhat.com/ml/gdb-patches/2001-06/msg00383.html http://sources.redhat.com/ml/gdb-patches/2001-06/msg00512.html http://sources.redhat.com/ml/gdb-patches/2001-07/msg00001.html will help figuring out the intent. > On Aug 16, 3:26pm, Daniel Jacobowitz wrote: > > > > Expressions like: > > > > > > /* Pass TRUE if our reason for stopping is something other > > > than hitting a breakpoint. We do this by checking that > > > 1) stepping is going on and 2) we didn't hit a breakpoint > > > in a signal handler without an intervening stop in > > > sigtramp, which is detected by a new stack pointer value > > > below any usual function calling stack adjustments. */ > > > (currently_stepping (ecs) > > > && prev_pc != stop_pc - DECR_PC_AFTER_BREAK > > > && !(step_range_end && INNER_THAN (read_sp (),(step_sp - 16))))); > > > > Which reminds me - does that use of INNER_THAN make even the slightest > > sense on stack-grows-up architectures? I don't think it does. > > I don't think so either. > > Also, that magical value of 16 just can't be right for all architectures. > > But this is one of those areas where we have to be *very* careful. > We can attempt to make well-meaning changes and then discover many > months later that we've broken something that used work. > > For the above, I think we need to figure out the intent behind the > condition > > INNER_THAN (read_sp (),(step_sp - 16), > > and then write an architecture dependent method for it. > > Kevin > > -- Peter Schauer pes@regent.e-technik.tu-muenchen.de