From: Mark Kettenis <kettenis@chello.nl>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()
Date: Mon, 05 Jan 2004 20:33:00 -0000 [thread overview]
Message-ID: <200401052033.i05KXcxx000617@elgar.kettenis.dyndns.org> (raw)
As suggested by Andrew, this removes the attempt to unwind the PC in
frame.c:get_prev_frame(). This bit of code shouldn't be necessary and
made it impossible to backtrace from a sentinel frame with PC == 0,
which would aroise from calling a null function pointer.
Andrew, I saw no use for retaining some of the commentd, so I delete
the thing completely.
Committed,
Mark
Index: ChangeLog
from Mark Kettenis <kettenis@gnu.org>
* frame.c (get_prev_frame): Don't try to unwind the PC. This
fixes PR backtrace/1476.
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.153
diff -u -p -r1.153 frame.c
--- frame.c 10 Dec 2003 17:40:42 -0000 1.153
+++ frame.c 5 Jan 2004 20:27:20 -0000
@@ -1943,37 +1943,6 @@ get_prev_frame (struct frame_info *this_
prev_frame = FRAME_OBSTACK_ZALLOC (struct frame_info);
prev_frame->level = this_frame->level + 1;
- /* Try to unwind the PC. If that doesn't work, assume we've reached
- the oldest frame and simply return. Is there a better sentinal
- value? The unwound PC value is then used to initialize the new
- previous frame's type.
-
- Note that the pc-unwind is intentionally performed before the
- frame chain. This is ok since, for old targets, both
- frame_pc_unwind (nee, FRAME_SAVED_PC) and
- DEPRECATED_FRAME_CHAIN()) assume THIS_FRAME's data structures
- have already been initialized (using
- DEPRECATED_INIT_EXTRA_FRAME_INFO) and hence the call order
- doesn't matter.
-
- By unwinding the PC first, it becomes possible to, in the case of
- a dummy frame, avoid also unwinding the frame ID. This is
- because (well ignoring the PPC) a dummy frame can be located
- using THIS_FRAME's frame ID. */
-
- if (frame_pc_unwind (this_frame) == 0)
- {
- /* The allocated PREV_FRAME will be reclaimed when the frame
- obstack is next purged. */
- if (frame_debug)
- {
- fprintf_unfiltered (gdb_stdlog, "-> ");
- fprint_frame (gdb_stdlog, NULL);
- fprintf_unfiltered (gdb_stdlog, " // unwound PC zero }\n");
- }
- return NULL;
- }
-
/* Don't yet compute ->unwind (and hence ->type). It is computed
on-demand in get_frame_type, frame_register_unwind, and
get_frame_id. */
next reply other threads:[~2004-01-05 20:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-05 20:33 Mark Kettenis [this message]
2004-01-05 21:57 ` Andrew Cagney
2004-01-05 23:01 ` Mark Kettenis
2004-01-05 23:46 ` Andrew Cagney
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=200401052033.i05KXcxx000617@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--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