From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17879 invoked by alias); 23 Jan 2009 20:15:13 -0000 Received: (qmail 17847 invoked by uid 22791); 23 Jan 2009 20:15:11 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Jan 2009 20:15:04 +0000 Received: (qmail 4073 invoked from network); 23 Jan 2009 20:15:02 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Jan 2009 20:15:02 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Remove call to deprecated_update_frame_pc_hack from normal_stop Date: Fri, 23 Jan 2009 20:15:00 -0000 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_HWieJ5Qz1g8nOHZ" Message-Id: <200901232016.07213.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00473.txt.bz2 --Boundary-00=_HWieJ5Qz1g8nOHZ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 506 Do you think there's still a case for having this around? We always decrement the PC first thing in handle_inferior_event, before reiniting the cache. Of all other cases I can think of that end up calling normal_stop, if we end up here without a call to reinit_frame_cache, this hack is wrong/insuficient anyway. While I'm at it, I can eliminate deprecated_update_frame_pc_hack and deprecated_update_frame_base_hack, by inlining them in their only caller left. Tested on x86_64-linux. -- Pedro Alves --Boundary-00=_HWieJ5Qz1g8nOHZ Content-Type: text/x-diff; charset="iso 8859-15"; name="deprecated_update_frame_pc_hack.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="deprecated_update_frame_pc_hack.diff" Content-length: 4720 2009-01-23 Pedro Alves * infrun.c (normal_stop): Don't call deprecated_update_frame_pc_hack. * frame.c (deprecated_update_frame_pc_hack) (deprecated_update_frame_base_hack): Delete, and ... (create_new_frame): ... inline here. --- gdb/frame.c | 40 ++++++---------------------------------- gdb/frame.h | 18 ------------------ gdb/infrun.c | 11 ----------- 3 files changed, 6 insertions(+), 63 deletions(-) Index: src/gdb/infrun.c =================================================================== --- src.orig/gdb/infrun.c 2009-01-23 19:18:01.000000000 +0000 +++ src/gdb/infrun.c 2009-01-23 19:18:20.000000000 +0000 @@ -4224,17 +4224,6 @@ normal_stop (void) previous_inferior_ptid = inferior_ptid; } - /* NOTE drow/2004-01-17: Is this still necessary? */ - /* Make sure that the current_frame's pc is correct. This - is a correction for setting up the frame info before doing - gdbarch_decr_pc_after_break */ - if (target_has_execution) - /* FIXME: cagney/2002-12-06: Has the PC changed? Thanks to - gdbarch_decr_pc_after_break, the program counter can change. Ask the - frame code to check for this and sort out any resultant mess. - gdbarch_decr_pc_after_break needs to just go away. */ - deprecated_update_frame_pc_hack (get_current_frame (), read_pc ()); - if (!breakpoints_always_inserted_mode () && target_has_execution) { if (remove_breakpoints ()) Index: src/gdb/frame.c =================================================================== --- src.orig/gdb/frame.c 2009-01-23 19:18:04.000000000 +0000 +++ src/gdb/frame.c 2009-01-23 19:59:54.000000000 +0000 @@ -1111,8 +1111,12 @@ create_new_frame (CORE_ADDR addr, CORE_A fi->unwind = frame_unwind_find_by_frame (fi, &fi->prologue_cache); fi->this_id.p = 1; - deprecated_update_frame_base_hack (fi, addr); - deprecated_update_frame_pc_hack (fi, pc); + fi->this_id.value.stack_addr = addr; + /* While we're at it, update this frame's cached PC value, found + in the next frame. Oh for the day when "struct frame_info" + is opaque and this hack on hack can just go away. */ + fi->next->prev_pc.value = pc; + fi->next->prev_pc.p = 1; if (frame_debug) { @@ -1730,38 +1734,6 @@ get_frame_type (struct frame_info *frame return frame->unwind->type; } -void -deprecated_update_frame_pc_hack (struct frame_info *frame, CORE_ADDR pc) -{ - if (frame_debug) - fprintf_unfiltered (gdb_stdlog, - "{ deprecated_update_frame_pc_hack (frame=%d,pc=0x%s) }\n", - frame->level, paddr_nz (pc)); - /* NOTE: cagney/2003-03-11: Some architectures (e.g., Arm) are - maintaining a locally allocated frame object. Since such frames - are not in the frame chain, it isn't possible to assume that the - frame has a next. Sigh. */ - if (frame->next != NULL) - { - /* While we're at it, update this frame's cached PC value, found - in the next frame. Oh for the day when "struct frame_info" - is opaque and this hack on hack can just go away. */ - frame->next->prev_pc.value = pc; - frame->next->prev_pc.p = 1; - } -} - -void -deprecated_update_frame_base_hack (struct frame_info *frame, CORE_ADDR base) -{ - if (frame_debug) - fprintf_unfiltered (gdb_stdlog, - "{ deprecated_update_frame_base_hack (frame=%d,base=0x%s) }\n", - frame->level, paddr_nz (base)); - /* See comment in "frame.h". */ - frame->this_id.value.stack_addr = base; -} - /* Memory access methods. */ void Index: src/gdb/frame.h =================================================================== --- src.orig/gdb/frame.h 2009-01-23 19:18:14.000000000 +0000 +++ src/gdb/frame.h 2009-01-23 19:23:10.000000000 +0000 @@ -660,22 +660,4 @@ extern struct frame_info *deprecated_saf extern struct frame_info *create_new_frame (CORE_ADDR base, CORE_ADDR pc); -/* FIXME: cagney/2002-12-06: Has the PC in the current frame changed? - "infrun.c", Thanks to gdbarch_decr_pc_after_break, can change the PC after - the initial frame create. This puts things back in sync. - - This replaced: frame->pc = ....; */ -extern void deprecated_update_frame_pc_hack (struct frame_info *frame, - CORE_ADDR pc); - -/* FIXME: cagney/2002-12-18: Has the frame's base changed? Or to be - more exact, was that initial guess at the frame's base as returned - by the deleted read_fp() wrong? If it was, fix it. This shouldn't - be necessary since the code should be getting the frame's base - correct from the outset. - - This replaced: frame->frame = ....; */ -extern void deprecated_update_frame_base_hack (struct frame_info *frame, - CORE_ADDR base); - #endif /* !defined (FRAME_H) */ --Boundary-00=_HWieJ5Qz1g8nOHZ--