From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8396 invoked by alias); 17 Jan 2004 22:39:07 -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 8389 invoked from network); 17 Jan 2004 22:39:06 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.4.239) by sources.redhat.com with SMTP; 17 Jan 2004 22:39:06 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3A9992B8F; Sat, 17 Jan 2004 17:38:42 -0500 (EST) Message-ID: <4009B971.50803@gnu.org> Date: Sat, 17 Jan 2004 22:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: Centralize DECR_PC_AFTER_BREAK handling from infrun References: <20040117222007.GA23563@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00455.txt.bz2 > 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. Otherwize, yow! Andrew