Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/3] Clear non-significant bits of address on memory access
Date: Tue, 19 Dec 2017 15:41:00 -0000	[thread overview]
Message-ID: <CAH=s-PNCha8QmnkM72spM33iHa8OCy5UZtmyxSvWhCH2VUM6_g@mail.gmail.com> (raw)
In-Reply-To: <20171219135048.A25D9D85C63@oc3748833570.ibm.com>

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 (齐尧)


  reply	other threads:[~2017-12-19 15:41 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08 10:04 [PATCH 0/3 v3] [AArch64] Support tagged pointer Yao Qi
2017-12-08 10:04 ` [PATCH 3/3] Clear non-significant bits of address in watchpoint Yao Qi
2017-12-08 12:23   ` Pedro Alves
2017-12-08 10:04 ` [PATCH 1/3] Clear non-significant bits of address on memory access Yao Qi
2017-12-08 12:22   ` Pedro Alves
2017-12-08 15:13     ` Ulrich Weigand
2017-12-08 15:36       ` Yao Qi
2017-12-19 13:50   ` Ulrich Weigand
2017-12-19 15:41     ` Yao Qi [this message]
2017-12-19 16:15       ` Ulrich Weigand
2017-12-20  9:57         ` Yao Qi
2017-12-20 13:03           ` [pushed] Fix Cell/B.E. regression (Re: [PATCH 1/3] Clear non-significant bits of address on memory access) Ulrich Weigand
2017-12-20 13:59             ` Yao Qi
2017-12-08 10:04 ` [PATCH 2/3] Adjust breakpoint address by clearing non-significant bits Yao Qi
2017-12-08 12:22   ` Pedro Alves
2017-12-08 12:24 ` [PATCH 0/3 v3] [AArch64] Support tagged pointer Pedro Alves
2017-12-08 17:31 ` Yao Qi
2018-04-11  0:16   ` Omair Javaid
2018-04-11  0:37     ` Omair Javaid
2018-04-11  2:46       ` Simon Marchi
2018-04-11 10:14     ` Pedro Alves
2018-04-11 11:13       ` Omair Javaid
2018-04-11 11:19         ` Pedro Alves
2018-04-11 12:01           ` Omair Javaid
2018-04-11 18:27             ` Pedro Alves
2018-04-16  1:36               ` Omair Javaid
2018-04-16 22:57                 ` Pedro Alves
2018-04-20 14:34                   ` Omair Javaid
2018-04-20 16:13                     ` Daniel Thompson
2018-04-23  7:50                       ` Omair Javaid
2018-04-24 11:39                         ` Pedro Alves
2018-04-24 15:44                           ` Daniel Thompson
2018-04-24 11:48                     ` Pedro Alves
2018-04-24 16:05                       ` Daniel Thompson
2018-04-24 23:42                         ` Omair Javaid
2018-04-25  0:09                           ` Andrew Pinski
2018-04-25  8:04                           ` Daniel Thompson
2018-04-26  8:11                             ` Omair Javaid
2018-04-27 16:29                               ` Daniel Thompson
2018-04-30 13:42                                 ` Omair Javaid

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH=s-PNCha8QmnkM72spM33iHa8OCy5UZtmyxSvWhCH2VUM6_g@mail.gmail.com' \
    --to=qiyaoltc@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox