From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Make Solaris/SPARC native work again
Date: Tue, 18 Feb 2003 22:52:00 -0000 [thread overview]
Message-ID: <1030218225209.ZM5499@localhost.localdomain> (raw)
I've just committed the patches below. These were necessary to make
Solaris/SPARC native work again. (There were actually two patches that
broke Solaris/SPARC. The first was committed on 2002-12-09 and the
second on 2003-01-06.)
* sparc-tdep.c (sparc_frame_chain): Adjust return value.
* config/sparc/tm-sparc.h (init_frame_pc_noop): Declare.
Index: sparc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc-tdep.c,v
retrieving revision 1.64
diff -u -p -r1.64 sparc-tdep.c
--- sparc-tdep.c 15 Jan 2003 19:35:27 -0000 1.64
+++ sparc-tdep.c 18 Feb 2003 22:43:46 -0000
@@ -431,8 +431,20 @@ sparc_frame_chain (struct frame_info *fr
{
/* Value that will cause FRAME_CHAIN_VALID to not worry about the chain
value. If it really is zero, we detect it later in
- sparc_init_prev_frame. */
- return (CORE_ADDR) 1;
+ sparc_init_prev_frame.
+
+ Note: kevinb/2003-02-18: The constant 1 used to be returned
+ here, but, after some recent changes to frame_chain_valid(),
+ this value is no longer suitable for causing frame_chain_valid()
+ to "not worry about the chain value." The constant ~0 (i.e,
+ 0xfff...) causes the failing test in frame_chain_valid() to
+ succeed thus preserving the "not worry" property. I had considered
+ using something like ``get_frame_base (frame) + 1''. However, I think
+ a constant value is better, because when debugging this problem,
+ I knew that something funny was going on as soon as I saw the
+ constant 1 being used as the frame chain elsewhere in GDB. */
+
+ return ~ (CORE_ADDR) 0;
}
CORE_ADDR
Index: config/sparc/tm-sparc.h
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/tm-sparc.h,v
retrieving revision 1.30
diff -u -p -r1.30 tm-sparc.h
--- config/sparc/tm-sparc.h 19 Jan 2003 04:06:47 -0000 1.30
+++ config/sparc/tm-sparc.h 18 Feb 2003 22:43:46 -0000
@@ -511,6 +511,10 @@ extern void sparc_print_extra_frame_info
/* INIT_EXTRA_FRAME_INFO needs the PC to detect flat frames. */
+/* NOTE: cagney/2002-12-08: Add local declaration of
+ init_frame_pc_noop() because it isn't possible to include
+ "arch-utils.h" here. */
+extern CORE_ADDR init_frame_pc_noop (int fromleaf, struct frame_info *prev);
#define DEPRECATED_INIT_FRAME_PC(FROMLEAF, PREV) (init_frame_pc_noop (FROMLEAF, PREV))
#define DEPRECATED_INIT_FRAME_PC_FIRST(FROMLEAF, PREV) \
((FROMLEAF) ? SAVED_PC_AFTER_CALL ((PREV)->next) : \
reply other threads:[~2003-02-18 22:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1030218225209.ZM5499@localhost.localdomain \
--to=kevinb@redhat.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