darlinghq/darling-gdb
1
0
Fork 0
mirror of https://github.com/darlinghq/darling-gdb.git synced 2024-11-26 05:20:30 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Index: ChangeLog

Browse Source 
2004-03-15  Andrew Cagney  <cagney@redhat.com>

	* 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.
This commit is contained in:
Andrew Cagney 2004-03-15 17:12:50 +00:00
parent 8ce8c090f3
commit 4fdf61212c
2 changed files with 56 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
gdb/ChangeLog
View File

@ -1,3 +1,9 @@
2004-03-15 Andrew Cagney <cagney@redhat.com>
* 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 <kettenis@gnu.org>
* amd64-linux-tdep.h: Remove file.

80
gdb/infrun.c
View File

@ -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 ()));