This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/3] Clear non-significant bits of address on memory access
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: qiyaoltc at gmail dot com (Yao Qi)
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 19 Dec 2017 14:50:48 +0100 (CET)
- Subject: Re: [PATCH 1/3] Clear non-significant bits of address on memory access
- Authentication-results: sourceware.org; auth=none
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