This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [commit, oops] New function pc_in_dummy_frame(pc)
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Sun, 24 Nov 2002 10:56:58 -0500
- Subject: Re: [commit, oops] New function pc_in_dummy_frame(pc)
- References: <3DE0EFE8.2090803@redhat.com>
There is a problem though (and I only noticed after committing it :-().
The change assumes that all architectures that use generic dummy frames also set PC_IN_CALL_DUMMY to generic_pc_in_call_dummy() (and hence eventually call this new pc_in_dummy_frame). Problem is, some don't:
cris, frv, i386, x86-64
They instead use pc_in_call_dummy_at_entry_point(). Now, in theory, generic_pc_in_call_dummy() and pc_in_call_dummy_at_entry_point() are equivalent, I'm not going to put money on it though. Hence, expect a follow up patch to revert a small part of this change.
I've checked in the attached.
Andrew
2002-11-24 Andrew Cagney <ac131313@redhat.com>
* frame.c (set_unwind_by_pc): Revert change below, use
PC_IN_CALL_DUMMY.
(get_prev_frame): Ditto.
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.30
diff -u -r1.30 frame.c
--- frame.c 24 Nov 2002 15:06:08 -0000 1.30
+++ frame.c 24 Nov 2002 15:39:20 -0000
@@ -656,7 +656,11 @@
*unwind_register = frame_saved_regs_register_unwind;
*unwind_pc = frame_saved_regs_pc_unwind;
}
- else if (pc_in_dummy_frame (pc))
+ /* FIXME: cagney/2002-11-24: Can't yet directly call
+ pc_in_dummy_frame() as some architectures don't set
+ PC_IN_CALL_DUMMY() to generic_pc_in_call_dummy() (remember the
+ latter is implemented by simply calling pc_in_dummy_frame). */
+ else if (PC_IN_CALL_DUMMY (pc, 0, 0))
{
*unwind_register = dummy_frame_register_unwind;
*unwind_pc = dummy_frame_pc_unwind;
@@ -694,7 +698,11 @@
has previously set it. This is really somewhat bogus. The
initialization, as seen in create_new_frame(), should occur
before the INIT function has been called. */
- if (USE_GENERIC_DUMMY_FRAMES && pc_in_dummy_frame (pc))
+ /* FIXME: cagney/2002-11-24: Can't yet directly call
+ pc_in_dummy_frame() as some architectures don't set
+ PC_IN_CALL_DUMMY() to generic_pc_in_call_dummy() (remember the
+ latter is implemented by simply calling pc_in_dummy_frame). */
+ if (USE_GENERIC_DUMMY_FRAMES && PC_IN_CALL_DUMMY (pc, 0, 0))
/* NOTE: cagney/2002-11-11: Does this even occure? */
type = DUMMY_FRAME;
else
@@ -975,8 +983,11 @@
has previously set it. This is really somewhat bogus. The
initialization, as seen in create_new_frame(), should occur
before the INIT function has been called. */
- if (USE_GENERIC_DUMMY_FRAMES
- && pc_in_dummy_frame (prev->pc))
+ /* FIXME: cagney/2002-11-24: Can't yet directly call
+ pc_in_dummy_frame() as some architectures don't set
+ PC_IN_CALL_DUMMY() to generic_pc_in_call_dummy() (remember the
+ latter is implemented by simply calling pc_in_dummy_frame). */
+ if (USE_GENERIC_DUMMY_FRAMES && PC_IN_CALL_DUMMY (prev->pc, 0, 0))
prev->type = DUMMY_FRAME;
else
{