From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5837 invoked by alias); 22 Nov 2007 16:25:37 -0000 Received: (qmail 5804 invoked by uid 22791); 22 Nov 2007 16:25:36 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 22 Nov 2007 16:25:29 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1IvErm-0004uy-00; Thu, 22 Nov 2007 16:25:26 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1IvEre-0000HM-00; Thu, 22 Nov 2007 16:25:18 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1IvEre-0003lY-GQ; Thu, 22 Nov 2007 16:25:18 +0000 Date: Thu, 22 Nov 2007 16:25:00 -0000 From: "Maciej W. Rozycki" To: gdb-patches@sourceware.org cc: Nigel Stephens , "Maciej W. Rozycki" Subject: utils.c: Sign-extend addresses if required by the target Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00413.txt.bz2 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 Maciej W. Rozycki * 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) \