* Patch: Fix handling for TYPE_CODE_INT in valops.c
@ 2007-02-22 14:33 Markus Deuling
2007-02-22 14:57 ` Daniel Jacobowitz
0 siblings, 1 reply; 4+ messages in thread
From: Markus Deuling @ 2007-02-22 14:33 UTC (permalink / raw)
To: GDB Patches; +Cc: Ulrich Weigand
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;
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Patch: Fix handling for TYPE_CODE_INT in valops.c
2007-02-22 14:33 Patch: Fix handling for TYPE_CODE_INT in valops.c Markus Deuling
@ 2007-02-22 14:57 ` Daniel Jacobowitz
2007-02-22 15:15 ` Ulrich Weigand
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Jacobowitz @ 2007-02-22 14:57 UTC (permalink / raw)
To: Markus Deuling; +Cc: GDB Patches, Ulrich Weigand
On Thu, Feb 22, 2007 at 03:33:10PM +0100, Markus Deuling wrote:
> 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 ?
Yes, I think this is OK. Thanks.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Patch: Fix handling for TYPE_CODE_INT in valops.c
2007-02-22 14:57 ` Daniel Jacobowitz
@ 2007-02-22 15:15 ` Ulrich Weigand
0 siblings, 0 replies; 4+ messages in thread
From: Ulrich Weigand @ 2007-02-22 15:15 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Markus Deuling, GDB Patches
Daniel Jakobowitz wrote:
> On Thu, Feb 22, 2007 at 03:33:10PM +0100, Markus Deuling wrote:
> > 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 ?
>
> Yes, I think this is OK. Thanks.
I've checked this in as well, thanks.
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Patch: Fix handling for TYPE_CODE_INT in valops.c
@ 2007-02-22 14:57 Markus Deuling
0 siblings, 0 replies; 4+ messages in thread
From: Markus Deuling @ 2007-02-22 14:57 UTC (permalink / raw)
To: GDB Patches; +Cc: Ulrich Weigand
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
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
[-- Attachment #2: diff-fix-valops --]
[-- Type: text/plain, Size: 505 bytes --]
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;
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-02-22 15:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-22 14:33 Patch: Fix handling for TYPE_CODE_INT in valops.c Markus Deuling
2007-02-22 14:57 ` Daniel Jacobowitz
2007-02-22 15:15 ` Ulrich Weigand
2007-02-22 14:57 Markus Deuling
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox