From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22564 invoked by alias); 17 Jan 2004 23:04:28 -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 22557 invoked from network); 17 Jan 2004 23:04:27 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Jan 2004 23:04:27 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AhzUR-0007uD-8d for ; Sat, 17 Jan 2004 18:04:27 -0500 Date: Sat, 17 Jan 2004 23:04:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFC: Centralize DECR_PC_AFTER_BREAK handling from infrun Message-ID: <20040117230427.GA30348@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040117222007.GA23563@nevyn.them.org> <4009B971.50803@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4009B971.50803@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00457.txt.bz2 On Sat, Jan 17, 2004 at 05:38:41PM -0500, Andrew Cagney wrote: > >The first, possibly most important step in cleaning up > >DECR_PC_AFTER_BREAK's > >tentacles. This changes handle_inferior_event to fix the PC immediately, > >before doing anything else with it. It removes the later decrements, but > >doesn't remove all the later workarounds for possibly undecremented PC > >values - that can come separately. > > > >One case, HANDLE_NONSTEPPABLE_WATCHPOINTS and DECR_PC_AFTER_BREAK, is > >simply > >removed. There are no targets using this combination, and if one is added, > >it's non-obvious whether a nonsteppable watchpoint really should be > >affected > >by DECR_PC_AFTER_BREAK. > > > >A future cleanup will change bpstat_stop_status to only take a CORE_ADDR > >argument. Also, I believe that both the tests for sigtramps and the use of > >deprecated_frame_update_pc_hack can go now, but I don't want to mix that in > >with this - esp. since I'm not sure how to test the former belief. > > Build gdb with gcov and then run the testsuite, it will quickly point > you at the "dead" code paths and hence how well it was really tested. Except, my hunch is it's related to some particular system's broken PTRACE_SINGLESTEP :( Well, if it doesn't show up on the systems I have available I think I'll remove it anyway (after 6.1) - then if we need to add it back we'll pick up a comment saying why it was necessary. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer