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

["Ulrich Weigand" <uweigand@de.ibm.com>]

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