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

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

Yao Qi wrote:
> On Tue, Dec 19, 2017 at 1:50 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> > 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.
> >
> 
> Right, or SPU memory address has 63 significant bits?  The top bit is 1.

It's a "merged" address space containing the PowerPC address space (with
top bit 0) as well as all the SPU address spaces (top bit 1, next 31 bits
the SPU ID, last 32 bit the address on that SPU).

I wouldn't need any of that if we actually supported "real" address spaces,
i.e. instead of always passing just a CORE_ADDR, use a pair of address-space
identifier and CORE_ADDR.  But that would be a huge change, and so I worked
around that by using the "merged" encoding.

> > 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 we use target_thread_architecture (inferior_ptid) instead?  If GDB
> still access SPU memory even program stops in PPU, this doesn't work.

Yes, that should still work (e.g. when the program stops anywhere, GDB
will check software watchpoints that may be simultaneously set in SPU
and PPU memory).  Therefore target_thread_architecture doesn't really 
solve the problem either.

> > Can this call not be pushed down further in the target stack, to below
> 
> I think you meant "Can this call be", without "not".
> 
> > the xfer_partial implementation in the spu-multiarch target?
> >
> 
> I am stilling thinking how to do it...  alternatively, do you like the appr=
> oach
> that we pass 'address' to gdbarch significant_addr_bits, and teach
> ppc32 gdbarch significant_addr_bits be aware of SPU address, that is,
> return 64 if the top bit is one (this address is the SPU address),
> otherwise, return 32 (this address is normal PPU address).

Well, a simple workaround is to just always set significant_addr_bits
to 64 in ppc as well.  (This just doesn't matter for actual ppc addresses.)
But that doesn't really look like a clean solution for the generic
multi-architecture case ...

Bye,
Ulrich

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