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@sourceware.org (GDB Patches)
Subject: Re: [PATCH 1/3] Clear non-significant bits of address on memory access
Date: Wed, 20 Dec 2017 09:57:00 -0000	[thread overview]
Message-ID: <868tdxlo28.fsf@gmail.com> (raw)
In-Reply-To: <20171219161526.58C31D85C63@oc3748833570.ibm.com> (Ulrich	Weigand's message of "Tue, 19 Dec 2017 17:15:26 +0100 (CET)")

"Ulrich Weigand" <uweigand@de.ibm.com> writes:

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

Nowadays, we strip non-significant bits in address, pass the stripped
address to target cache and to_xfer_partial.  It works for aarch64, but
breaks ppc32/spu.  However, in ppc32/spu case, ppu address and spu
address is mixed together, differentiated by the top bit, so the number
of significant bits of address is 64, because if we can't remove any of
them.  IMO, it is reasonable to set significant_addr_bits to 64 in ppc.

I considered your suggestion that pushing address_significant call down,
below spu-multiarch target, that means, many target's to_xfer_partial
need to call address_significant, so I don't do that.  Secondly, in the
way you suggested, we still pass the original address to target cache,
which works for ppu/spu, but it doesn't work for aarch64.

-- 
Yao (齐尧)


  reply	other threads:[~2017-12-20  9:57 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 2/3] Adjust breakpoint address by clearing non-significant bits Yao Qi
2017-12-08 12:22   ` 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
2017-12-19 16:15       ` Ulrich Weigand
2017-12-20  9:57         ` Yao Qi [this message]
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 3/3] Clear non-significant bits of address in watchpoint Yao Qi
2017-12-08 12:23   ` 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=868tdxlo28.fsf@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