Re: [PATCH 1/3] Clear non-significant bits of address on memory access

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Yao Qi wrote:

> diff --git a/gdb/target.c b/gdb/target.c
> index 3b8b8ea..767a2ad 100644
> --- a/gdb/target.c
> +++ b/gdb/target.c
> @@ -1214,6 +1214,8 @@ memory_xfer_partial (struct target_ops *ops, enum target_object object,
>    if (len == 0)
>      return TARGET_XFER_EOF;
>  
> +  memaddr = address_significant (target_gdbarch (), memaddr);
> +
>    /* Fill in READBUF with breakpoint shadows, or WRITEBUF with
>       breakpoint insns, thus hiding out from higher layers whether
>       there are software breakpoints inserted in the code stream.  */

It turns out this breaks SPU multi-architecture debugging.  The problem is
that SPU memory addresses have 64 significant bits since we encode the
SPU ID in the upper 32 bits.  This means that spu-tdep.c needs to call
set_gdbarch_significant_addr_bits -- which is fine.

However, this doesn't fix the problem, since "target_gdbarch ()" at this
point may well return a (32-bit) ppc architecture, and then the address
is still truncated incorrectly.  In general, using target_gdbarch is
nearly never the right thing to do in generic code as long as we want
to support multi-architecture debugging.

Can this call not be pushed down further in the target stack, to below
the xfer_partial implementation in the spu-multiarch target?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com