This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: fix warning building spu-tdep.c
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: tromey at redhat dot com
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 5 Aug 2009 15:50:29 +0200 (CEST)
- Subject: Re: RFA: fix warning building spu-tdep.c
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