From: "Maciej W. Rozycki" <macro@mips.com>
To: gdb-patches@sourceware.org
Cc: Nigel Stephens <nigel@mips.com>,
"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: utils.c: Sign-extend addresses if required by the target
Date: Thu, 22 Nov 2007 16:25:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.61.0711221606400.15819@perivale.mips.com> (raw)
Hello,
There is at least one architecture, which is the MIPS one, that expands
addresses from 32-bits to 64-bits by doing sign-extension. It matters for
32-bit compatibility kernel addresses, which are defined with bits 31:63
set to one. For these addresses, if the compatibility mode is used, it is
common to input them as 32-bit hexadecimal constants as it would be the
case with 32-bit processors. However, BFD for the MIPS target is always
64-bit and if the processor used is indeed 64-bit, these addresses have to
be properly sign-extended to 64 bits.
Here is probably one of the last remaining places where it is not done.
The string_to_core_addr() is only used by the MI and Insight frontends and
then kernel addresses are only seen on bare-iron targets (e.g. not under
Linux, where user addresses are used only), so the problem may have
escaped for that long.
There is a note by Nigel included that perhaps this should be done
through the architecture vector. Well, I am not sure it is useful to add
such a member there just for this single place, but perhaps it would be a
good idea to clean up all the places it is done as a whole. It fixes a
regression though, so I think it is a useful fix, and the clean-up could
be done separately, so the note should probably be kept.
Tested for using the mipsisa32-sde-elf target, with the
mips-sim-sde32/-EB, mips-sim-sde32/-EL, mips-sim-sde64/-mips64/-EB and
mips-sim-sde64/-mips64/-EL boards removing 2 regressions -- this one:
-var-create a2 0x807fffa8 a
^done,name="a2",numchild="0",value="2 '\\002'",type="char"
(gdb)
FAIL: gdb.mi/mi-var-display.exp: create variable a2 in different scope
and similarly for gdb.mi/mi2-var-display.exp.
2007-11-22 Nigel Stephens <nigel@mips.com>
Maciej W. Rozycki <macro@mips.com>
* utils.c (string_to_core_addr): If executable format indicates
that addresses should be sign-extended and there are only 8 hex
digits in the address, then do so.
* Makefile.in (utils.o): Depend on $(gdbcore_h).
OK to apply?
Maciej
14524.diff
Index: binutils-quilt/src/gdb/utils.c
===================================================================
--- binutils-quilt.orig/src/gdb/utils.c 2007-11-21 11:25:32.000000000 +0000
+++ binutils-quilt/src/gdb/utils.c 2007-11-22 14:08:27.000000000 +0000
@@ -52,6 +52,7 @@
#include "filenames.h"
#include "symfile.h"
#include "gdb_obstack.h"
+#include "gdbcore.h"
#include "top.h"
#include "inferior.h" /* for signed_pointer_to_address */
@@ -2824,7 +2825,9 @@
CORE_ADDR
string_to_core_addr (const char *my_string)
{
+ int addr_bit = gdbarch_addr_bit (current_gdbarch);
CORE_ADDR addr = 0;
+
if (my_string[0] == '0' && tolower (my_string[1]) == 'x')
{
/* Assume that it is in hex. */
@@ -2838,6 +2841,17 @@
else
error (_("invalid hex \"%s\""), my_string);
}
+
+ /* Not very modular, but if the executable format expects
+ addresses to be sign-extended, then do so if the address was
+ specified with only 32 significant bits. Really this should
+ be determined by the target architecture, not by the object
+ file. */
+ if (i - 2 == addr_bit / 4
+ && exec_bfd
+ && bfd_get_sign_extend_vma (exec_bfd))
+ addr = (addr ^ ((CORE_ADDR) 1 << (addr_bit - 1)))
+ - ((CORE_ADDR) 1 << (addr_bit - 1));
}
else
{
@@ -2851,6 +2865,7 @@
error (_("invalid decimal \"%s\""), my_string);
}
}
+
return addr;
}
Index: binutils-quilt/src/gdb/Makefile.in
===================================================================
--- binutils-quilt.orig/src/gdb/Makefile.in 2007-11-21 11:34:19.000000000 +0000
+++ binutils-quilt/src/gdb/Makefile.in 2007-11-22 14:01:00.000000000 +0000
@@ -2892,7 +2892,7 @@
$(exceptions_h) $(tui_h) $(gdbcmd_h) $(serial_h) $(bfd_h) \
$(target_h) $(demangle_h) $(expression_h) $(language_h) $(charset_h) \
$(annotate_h) $(filenames_h) $(symfile_h) $(inferior_h) $(top_h) \
- $(gdb_curses_h) $(readline_h) $(gdb_obstack_h)
+ $(gdb_curses_h) $(readline_h) $(gdb_obstack_h) $(gdbcore_h)
v850-tdep.o: v850-tdep.c $(defs_h) $(frame_h) $(frame_base_h) $(trad_frame_h) \
$(frame_unwind_h) $(dwarf2_frame_h) $(gdbtypes_h) $(inferior_h) \
$(gdb_string_h) $(gdb_assert_h) $(gdbcore_h) $(arch_utils_h) \
next reply other threads:[~2007-11-22 16:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-22 16:25 Maciej W. Rozycki [this message]
2007-12-16 21:43 ` Daniel Jacobowitz
2007-12-17 17:47 ` Maciej W. Rozycki
2007-12-17 17:50 ` Daniel Jacobowitz
2007-12-17 18:35 ` Maciej W. Rozycki
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=Pine.LNX.4.61.0711221606400.15819@perivale.mips.com \
--to=macro@mips.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@linux-mips.org \
--cc=nigel@mips.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