RFA: fix warning building spu-tdep.c

RFA: fix warning building spu-tdep.c

[Tom Tromey]

I got this error while building gdb cvs on x86 F11 yesterday:

../../src/gdb/spu-tdep.c: In function ‘spu_gdbarch_id’:
../../src/gdb/spu-tdep.c:362: error: overflow in implicit constant conversion
../../src/gdb/spu-tdep.c: In function ‘gdb_print_insn_spu’:
../../src/gdb/spu-tdep.c:1597: error: overflow in implicit constant conversion
../../src/gdb/spu-tdep.c: In function ‘spu_overlay_update_osect’:
../../src/gdb/spu-tdep.c:1739: error: large integer implicitly truncated to unsigned type

The problem is that CORE_ADDR is 4 bytes here, but LONGEST is 8.

The fix is to change SPUADDR_SPU to cast its result to CORE_ADDR.  This
seems to be what is expected -- but, some places use int while others
use CORE_ADDR, so I did not want to commit this without review from
someone who knows the intent of this macro.

Tom

2009-08-04  Tom Tromey  <tromey@redhat.com>

	* spu-tdep.h (SPUADDR_SPU): Cast result to CORE_ADDR.

Index: spu-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/spu-tdep.h,v
retrieving revision 1.7
diff -u -r1.7 spu-tdep.h
--- spu-tdep.h	31 Jul 2009 15:28:27 -0000	1.7
+++ spu-tdep.h	4 Aug 2009 14:48:10 -0000
@@ -54,7 +54,9 @@
 #define SPUADDR(spu, addr) \
   ((spu) != -1? (ULONGEST)1 << 63 | (ULONGEST)(spu) << 32 | (addr) : (addr))
 #define SPUADDR_SPU(addr) \
-  (((addr) & (ULONGEST)1 << 63)? (ULONGEST)(addr) >> 32 & 0x7fffffff : -1)
+  (((addr) & (ULONGEST)1 << 63) \
+   ? (CORE_ADDR) ((ULONGEST)(addr) >> 32 & 0x7fffffff) \
+   : -1)
 #define SPUADDR_ADDR(addr) \
   (((addr) & (ULONGEST)1 << 63)? (ULONGEST)(addr) & 0xffffffff : (addr))
 

Re: RFA: fix warning building spu-tdep.c

[Ulrich Weigand]

Tom Tromey wrote:

> The problem is that CORE_ADDR is 4 bytes here, but LONGEST is 8.

Huh.  I'm assuming this happens when using --enable-targets=all
on a 32-bit host with a 32-bit primary target, right?  If "spu"
is the primary target, or is explicitly mentioned as secondary
target, CORE_ADDR should be automatically chosen as an 8-byte
type ...

> The fix is to change SPUADDR_SPU to cast its result to CORE_ADDR.  This
> seems to be what is expected -- but, some places use int while others
> use CORE_ADDR, so I did not want to commit this without review from
> someone who knows the intent of this macro.

The SPU ID is really an "int" (it's basically a file descriptor).  There
is indeed one place (spu_overlay_update_osect) that stores it into a
variable of type CORE_ADDR, but that's an oversight that should be fixed.

> 2009-08-04  Tom Tromey  <tromey@redhat.com>
> 
> 	* spu-tdep.h (SPUADDR_SPU): Cast result to CORE_ADDR.

If you change this to cast to "int" instead, this would be OK with me.

However, even so support for Cell/B.E. combined debugging will still
fail if CORE_ADDR is a 4-byte type, because the encoding of a pair
of SPU ID and address into a single CORE_ADDR value will fail --
this set of macros fundamentally assumed a CORE_ADDR that is (at
least) 64 bits wide ...

I'll have a look at how this can be fixed.  Probably we need to
enable support only with --enable-64-bit-bfd.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: RFA: fix warning building spu-tdep.c

[Tom Tromey]

>>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:

Ulrich> Huh.  I'm assuming this happens when using --enable-targets=all
Ulrich> on a 32-bit host with a 32-bit primary target, right?

Yes, that's right.

Ulrich> If you change this to cast to "int" instead, this would be OK with me.

Thanks.  I'll commit this shortly.

Ulrich> I'll have a look at how this can be fixed.  Probably we need to
Ulrich> enable support only with --enable-64-bit-bfd.

Yeah.  Maybe I ought to configure with that option.

Tom