From: David Mosberger <davidm@napali.hpl.hp.com>
To: gdb-patches@sources.redhat.com
Cc: davidm@napali.hpl.hp.com
Subject: new gdb arch routine FRAME_UNCHANGED
Date: Fri, 10 May 2002 17:23:00 -0000 [thread overview]
Message-ID: <200205110023.g4B0NVCF004832@napali.hpl.hp.com> (raw)
The patch below defines a new gdbarch routine called FRAME_UNCHANGED.
This is needed for gdb/ia64 because the ia64 architecture has two
separate stack pointers (one for memory stack and one for register stack).
Because of the two stacks, it's not possible to look just at the frame
pointer and PC to determine whether a frame changed.
If the patch looks OK, I'd appreciate if someone could apply it.
Note: the patch below doesn't include the ia64 version of
FRAME_UNCHANGED. It is part of a larger update to add unwind library
support to gdb/ia64 and I'll submit that separately. So, for now, the
patch is effectively a no-op for all platforms.
Also, it will be necessary to re-generate gdbarch.[ch] after applying
the patch.
Thanks,
--david
ChangeLog
2002-05-08 David Mosberger-Tang <David.Mosberger@acm.org>
* gdbarch.sh (FRAME_UNCHANGED): New routine.
* frame.h: Declare default_frame_unchanged() and
generic_dummy_frame_chain().
* blockframe.c (default_frame_unchanged): New function.
(get_prev_frame): Use FRAME_UNCHANGED() to determine whether
the new frame is different from the old one.
diff -u -r1.134 gdbarch.sh
--- gdbarch.sh 8 May 2002 20:43:04 -0000 1.134
+++ gdbarch.sh 9 May 2002 05:33:48 -0000
@@ -548,6 +548,7 @@
f:2:BREAKPOINT_FROM_PC:const unsigned char *:breakpoint_from_pc:CORE_ADDR *pcptr, int *lenptr:pcptr, lenptr:::legacy_breakpoint_from_pc::0
f:2:MEMORY_INSERT_BREAKPOINT:int:memory_insert_breakpoint:CORE_ADDR addr, char *contents_cache:addr, contents_cache::0:default_memory_insert_breakpoint::0
f:2:MEMORY_REMOVE_BREAKPOINT:int:memory_remove_breakpoint:CORE_ADDR addr, char *contents_cache:addr, contents_cache::0:default_memory_remove_breakpoint::0
+f:2:FRAME_UNCHANGED:int:frame_unchanged:struct frame_info *prev, struct frame_info *next:prev, next::0:default_frame_unchanged::0
v:2:DECR_PC_AFTER_BREAK:CORE_ADDR:decr_pc_after_break::::0:-1
f::PREPARE_TO_PROCEED:int:prepare_to_proceed:int select_it:select_it::0:default_prepare_to_proceed::0
v:2:FUNCTION_START_OFFSET:CORE_ADDR:function_start_offset::::0:-1
diff -u -r1.27 blockframe.c
--- blockframe.c 5 May 2002 01:15:12 -0000 1.27
+++ blockframe.c 9 May 2002 05:33:25 -0000
@@ -39,6 +39,16 @@
void _initialize_blockframe (void);
+/* Default FRAME_UNCHANGED. Returns true if the current and next
+ frame have the same frame address and the same PC. This version
+ should work for most platforms. One exception is ia64, since it
+ has separate memory and register stacks. */
+int
+default_frame_unchanged (struct frame_info *prev, struct frame_info *next)
+{
+ return (prev->frame == next->frame && prev->pc == next->pc);
+}
+
/* A default FRAME_CHAIN_VALID, in the form that is suitable for most
targets. If FRAME_CHAIN_VALID returns zero it means that the given
frame is the outermost one and has no caller. */
@@ -447,8 +457,7 @@
this can't be an architecture-independent check. */
if (next_frame != NULL)
{
- if (prev->frame == next_frame->frame
- && prev->pc == next_frame->pc)
+ if (FRAME_UNCHANGED (prev, next_frame))
{
next_frame->prev = NULL;
obstack_free (&frame_cache_obstack, prev);
diff -u -r1.17 frame.h
--- frame.h 5 May 2002 02:24:38 -0000 1.17
+++ frame.h 9 May 2002 05:33:38 -0000
@@ -160,6 +160,12 @@
#define FRAME_FP(fi) ((fi)->frame)
+/* Define a default FRAME_UNCHANGED in the form that that is suitable
+ for most targets. If FRAME_UNCHANGED returns zero it means that
+ the two frames are indistinguishable. */
+
+extern int default_frame_unchanged (struct frame_info *, struct frame_info *);
+
/* Level of the frame: 0 for innermost, 1 for its caller, ...; or -1
for an invalid frame. */
next reply other threads:[~2002-05-11 0:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-10 17:23 David Mosberger [this message]
2002-05-10 18:04 ` Andrew Cagney
2002-05-10 19:05 ` David Mosberger
2002-05-11 20:52 ` Andrew Cagney
2002-05-13 14:15 ` David Mosberger
2002-05-13 15:46 ` Andrew Cagney
2002-05-13 15:57 ` Kevin Buettner
2002-05-13 16:14 ` Andrew Cagney
2002-05-13 19:43 ` David Mosberger
2002-05-13 19:57 ` Andrew Cagney
2002-05-13 20:33 ` David Mosberger
2002-06-26 20:26 ` 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=200205110023.g4B0NVCF004832@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=davidm@hpl.hp.com \
--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