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

Ulrich Weigand
2017-12-19T13:50:59Z

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