From 4e25f039662e75f6849ff311ae541b7a83681aa2 Mon Sep 17 00:00:00 2001 From: cagney Date: Mon, 15 Mar 2004 17:12:48 +0000 Subject: [PATCH] Index: ChangeLog 2004-03-15 Andrew Cagney * infrun.c (handle_step_into_function, step_over_function): Only update and use STEP_FRAME_ID when the system is using legacy frames. Update comments. --- gdb/ChangeLog | 6 +++++ gdb/infrun.c | 80 +++++++++++++++++++++++++++++++++++++---------------------- 2 files changed, 56 insertions(+), 30 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index e8dca8fd67..ebe5913e74 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,9 @@ +2004-03-15 Andrew Cagney + + * infrun.c (handle_step_into_function, step_over_function): Only + update and use STEP_FRAME_ID when the system is using legacy + frames. Update comments. + 2004-03-14 Mark Kettenis * amd64-linux-tdep.h: Remove file. diff --git a/gdb/infrun.c b/gdb/infrun.c index 19dd807515..a863140670 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1264,17 +1264,22 @@ handle_step_into_function (struct execution_control_state *ecs) { /* We're doing a "next". */ - if (pc_in_sigtramp (stop_pc) + if (legacy_frame_p (current_gdbarch) + && pc_in_sigtramp (stop_pc) && frame_id_inner (step_frame_id, frame_id_build (read_sp (), 0))) - /* 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. */ + /* 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); @@ -2868,11 +2873,10 @@ step_into_function (struct execution_control_state *ecs) However, if the callee is recursing, we want to be careful not to catch returns of those recursive calls, but only of THIS instance - of the call. + of the caller. To do this, we set the step_resume bp's frame to our current - caller's frame (step_frame_id, which is set by the "next" or - "until" command, before execution begins). */ + caller's frame (obtained by doing a frame ID unwind). */ static void step_over_function (struct execution_control_state *ecs) @@ -2923,24 +2927,40 @@ step_over_function (struct execution_control_state *ecs) check_for_old_step_resume_breakpoint (); - 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. */ - sr_id = step_frame_id; - else if (legacy_frame_p (current_gdbarch)) - /* NOTE: cagney/2004-02-27: 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 ()); + /* 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 = get_frame_id (get_prev_frame (get_current_frame ())); -- 2.11.0