This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, Dec 19, 2017 at 1:50 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> 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.
>

Right, or SPU memory address has 63 significant bits?  The top bit is 1.

> 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.

> 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 approach
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).

-- 
Yao (齐尧)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]