From 08e69816c75406cb346264bab410151813cbd64f Mon Sep 17 00:00:00 2001 From: Andrew Cagney Date: Fri, 2 Apr 2004 20:35:09 +0000 Subject: [PATCH] 2004-04-02 Andrew Cagney * infrun.c (handle_step_into_function): Delete code conditional on legacy_frame_p. (handle_inferior_event, step_over_function): Ditto. --- gdb/ChangeLog | 6 ++++ gdb/infrun.c | 77 ++++++++------------------------------------------- 2 files changed, 18 insertions(+), 65 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 151ade1e44..c7c084d6e5 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,9 @@ +2004-04-02 Andrew Cagney + + * infrun.c (handle_step_into_function): Delete code conditional on + legacy_frame_p. + (handle_inferior_event, step_over_function): Ditto. + 2004-04-02 Andrew Cagney * frame.c (get_prev_frame_1): Exclude signal trampolines from the diff --git a/gdb/infrun.c b/gdb/infrun.c index b1d03e3ca4..66a8adf4a9 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1263,25 +1263,6 @@ handle_step_into_function (struct execution_control_state *ecs) if (step_over_calls == STEP_OVER_ALL || IGNORE_HELPER_CALL (stop_pc)) { /* We're doing a "next". */ - - if (legacy_frame_p (current_gdbarch) - && pc_in_sigtramp (stop_pc) - && frame_id_inner (step_frame_id, - frame_id_build (read_sp (), 0))) - /* NOTE: cagney/2004-03-15: This is only needed for legacy - systems. On non-legacy systems step_over_function doesn't - use STEP_FRAME_ID and hence the below update "hack" isn't - needed. */ - /* We stepped out of a signal handler, and into its calling - trampoline. This is misdetected as a subroutine call, but - stepping over the signal trampoline isn't such a bad idea. - In order to do that, we have to ignore the value in - step_frame_id, since that doesn't represent the frame - that'll reach when we return from the signal trampoline. - Otherwise we'll probably continue to the end of the - program. */ - step_frame_id = null_frame_id; - step_over_function (ecs); keep_going (ecs); return; @@ -2523,16 +2504,8 @@ process_event_stop_test: /* Did we just step into a singal trampoline (either by stepping out of a handler, or by taking a signal)? */ - /* NOTE: cagney/2004-03-16: Replaced (except for legacy) a check for - "pc_in_sigtramp(stop_pc) != pc_in_sigtramp(step_pc)" with - frame_type == SIGTRAMP && !frame_id_eq. The latter is far more - robust as it will correctly handle nested signal trampolines. */ - if (legacy_frame_p (current_gdbarch) - ? (pc_in_sigtramp (stop_pc) - && !pc_in_sigtramp (prev_pc) - && INNER_THAN (read_sp (), step_sp)) - : (get_frame_type (get_current_frame ()) == SIGTRAMP_FRAME - && !frame_id_eq (get_frame_id (get_current_frame ()), step_frame_id))) + if (get_frame_type (get_current_frame ()) == SIGTRAMP_FRAME + && !frame_id_eq (get_frame_id (get_current_frame ()), step_frame_id)) { { struct frame_id current_frame = get_frame_id (get_current_frame ()); @@ -2924,42 +2897,16 @@ step_over_function (struct execution_control_state *ecs) check_for_old_step_resume_breakpoint (); - /* NOTE: cagney/2004-03-15: Code using the current value of - "step_frame_id", instead of unwinding that frame ID, removed (at - least for non-legacy platforms). On s390 GNU/Linux, after taking - a signal, the program is directly resumed at the signal handler - and, consequently, the PC would point at at the first instruction - of that signal handler but STEP_FRAME_ID would [incorrectly] at - the interrupted code when it should point at the signal - trampoline. By always and locally doing a frame ID unwind, it's - possible to assert that the code is always using the correct - ID. */ - if (legacy_frame_p (current_gdbarch)) - { - if (frame_id_p (step_frame_id) - && !IN_SOLIB_DYNSYM_RESOLVE_CODE (sr_sal.pc)) - /* NOTE: cagney/2004-02-27: Use the global state's idea of the - stepping frame ID. I suspect this is done as it is lighter - weight than a call to get_prev_frame. */ - /* NOTE: cagney/2004-03-15: See comment above about how this - is also broken. */ - sr_id = step_frame_id; - else - /* NOTE: cagney/2004-03-15: This is the way it was 'cos this - is the way it always was. It should be using the unwound - (or caller's) ID, and not this (or the callee's) ID. It - appeared to work because: legacy architectures used the - wrong end of the frame for the ID.stack (inner-most rather - than outer-most) so that the callee's id.stack (un - adjusted) matched the caller's id.stack giving the - "correct" id; more often than not - !IN_SOLIB_DYNSYM_RESOLVE_CODE and hence the code above (it - was originally later in the function) fixed the ID by using - global state. */ - sr_id = get_frame_id (get_current_frame ()); - } - else - sr_id = frame_unwind_id (get_current_frame ()); + /* NOTE: cagney/2004-03-31: Code using the current value of + "step_frame_id", instead of unwinding that frame ID, removed. On + s390 GNU/Linux, after taking a signal, the program is directly + resumed at the signal handler and, consequently, the PC would + point at at the first instruction of that signal handler but + STEP_FRAME_ID would [incorrectly] at the interrupted code when it + should point at the signal trampoline. By always and locally + doing a frame ID unwind, it's possible to assert that the code is + always using the correct ID. */ + sr_id = frame_unwind_id (get_current_frame ()); step_resume_breakpoint = set_momentary_breakpoint (sr_sal, sr_id, bp_step_resume);