This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Patch: Fix handling for TYPE_CODE_INT in valops.c
- From: Markus Deuling <deuling at de dot ibm dot com>
- To: GDB Patches <gdb-patches at sourceware dot org>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Thu, 22 Feb 2007 15:56:41 +0100
- Subject: Patch: Fix handling for TYPE_CODE_INT in valops.c
Hi,
I've seen errors when debugging a SPU target.
Accessing e.g. a variable by its address failes:
(gbd) p test_var
$2 = 5
(gdb) x/x &test_var
0x2b50 <test_var.4254>: 0x00000005
(gdb) p *0x2b50
Cannot access memory at address 0x2b50
The architecture specific callback integer_to_address() isn't called, so that's why in this case 0x2b50 isn't converted to a combined address as it should. The patch calls value_as_address instead of value_as_long to handle a TYPE_CODE_INT.
Running the test suite showed no regressions both on x86 and SPU.
Ok to commit ?
ChangeLog:
* valops.c (value_ind): Fix unary * handling
of TYPE_CODE_INT.
Regards,
Markus
--
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com
diff -urN src/gdb/valops.c dev/gdb/valops.c
--- src/gdb/valops.c 2007-01-09 18:58:59.000000000 +0100
+++ dev/gdb/valops.c 2007-02-22 14:41:04.000000000 +0100
@@ -934,7 +934,7 @@
BUILTIN_TYPE_LONGEST would seem to be a mistake. */
if (TYPE_CODE (base_type) == TYPE_CODE_INT)
return value_at_lazy (builtin_type_int,
- (CORE_ADDR) value_as_long (arg1));
+ (CORE_ADDR) value_as_address (arg1));
else if (TYPE_CODE (base_type) == TYPE_CODE_PTR)
{
struct type *enc_type;