From: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>
To: cagney@gnu.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Fix signals.exp test case on S/390
Date: Thu, 11 Mar 2004 00:09:00 -0000 [thread overview]
Message-ID: <200403110007.BAA05694@faui1d.informatik.uni-erlangen.de> (raw)
Message-ID: <20040311000900.ndWAU91pHd9XW9W5fZIg7ZpyTDKCSUpJhZ5ncZL08Jw@z> (raw)
Andrew Cagney wrote:
>I'm lost here. What happens with:
>
>- get_frame_id (get_prev_frame (signal handler))
>- get_frame_id (sigreturn trampoline)
>
>They should match
Well, they do match, that's why things work with my patch.
The problem is that without my patch, step_over_function
doesn't actually *use* get_frame_id (get_prev_frame ...),
see the code:
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 ());
else
sr_id = get_frame_id (get_prev_frame (get_current_frame ()));
It will run into the first if, and simply use step_frame_id,
which is wrong in this case. That's why my patch add another
condition to the first if, to make it not taken and actually
use the (correct) get_prev_frame case.
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
next reply other threads:[~2004-03-11 0:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-19 0:09 Ulrich Weigand [this message]
2004-03-11 0:09 ` Ulrich Weigand
2004-03-19 0:09 ` Andrew Cagney
2004-03-11 16:08 ` Andrew Cagney
2004-03-19 0:09 ` Ulrich Weigand
2004-03-11 17:11 ` Ulrich Weigand
2004-03-15 17:12 ` [commit] Don't use STEP_FRAME_ID; Was: " Andrew Cagney
2004-03-17 19:15 ` [commit] Don't use STEP_FRAME_ID; Was: [PATCH] Fix signals.exp test Ulrich Weigand
2004-03-19 0:09 ` Ulrich Weigand
2004-03-19 0:09 ` [commit] Don't use STEP_FRAME_ID; Was: [PATCH] Fix signals.exp test case on S/390 Andrew Cagney
-- strict thread matches above, loose matches on Subject: below --
2004-03-10 20:32 Ulrich Weigand
2004-03-10 23:25 ` Andrew Cagney
2004-03-19 0:09 ` Andrew Cagney
2004-03-19 0:09 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200403110007.BAA05694@faui1d.informatik.uni-erlangen.de \
--to=weigand@i1.informatik.uni-erlangen.de \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox