From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3500 invoked by alias); 16 Aug 2002 19:26:29 -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 3493 invoked from network); 16 Aug 2002 19:26:28 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Aug 2002 19:26:28 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17fmjt-0004vu-00; Fri, 16 Aug 2002 14:26:29 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17fmkK-0001PI-00; Fri, 16 Aug 2002 15:26:56 -0400 Date: Fri, 16 Aug 2002 12:26:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: [RFA] enable software single step on alpha-osf Message-ID: <20020816192655.GA5213@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Joel Brobecker , gdb-patches@sources.redhat.com References: <20020718203205.GB26990@gnat.com> <3D4DBBC8.5000906@ges.redhat.com> <20020805184920.GC892@gnat.com> <3D5D323A.2030801@ges.redhat.com> <20020816182141.GJ906@gnat.com> <3D5D4E46.7080902@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5D4E46.7080902@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00445.txt.bz2 On Fri, Aug 16, 2002 at 03:11:02PM -0400, Andrew Cagney wrote: > > >So, to summarize: > > > > 1 - The change "+ stop_pc -= DECR_PC_AFTER_BREAK;" seems > > to be going in the right direction. > > > > 2 - However I should hold this change for now because you think I should > > write the adjusted PC value back to the target, by adding something > > like "write_pc_pid (stop_pc, ecs->ptid)" > > > > I will verify the impact of such a change, and report. > > > > 3 - Assuming we get all issues in this RFA resolved, then I will start > > looking at the addition of the software_singlestep flag. > > I think the flag should be added as part of the change. That way we're > 100% certain that bpstat_stop_status() isn't going to do a > decr_pc_after_break. > > 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. > would be changed to read: > > (trap_was_a_software_singlestep > || ....) > > Hmm, looking at the above, on an architecture like the i386, the test > ``prev_pc != stop_pc - DECR_PC_AFTER_BREAK'' is probably false when if > the code has just stepped off a single byte instruction :-( Is there some way we can do this without growing that condition? It's awful, and it makes very little sense; it feels like something that should already have been handled. Yes, I'm trying to trick Joel into doing some of the DECR_PC_AFTER_BREAK cleanups that everyone keeps meaning to do. It's just not being handled somewhere useful right now. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer