public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Omair Javaid <omair.javaid@linaro.org>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Pedro Alves <palves@redhat.com>, Yao Qi <qiyaoltc@gmail.com>,
		GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer
Date: Thu, 26 Apr 2018 08:11:00 -0000	[thread overview]
Message-ID: <CANW4E-1c8Ck_4Y52Avi1emJij90q9g8BiSvNQp4dKkdWkQonqw@mail.gmail.com> (raw)
In-Reply-To: <20180425080432.kv4gagdcz7mhmx4x@holly.lan>

On 25 April 2018 at 13:04, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> On Wed, Apr 25, 2018 at 04:41:40AM +0500, Omair Javaid wrote:
>> >> If everyone agrees that proper Linux kernel support benefits from
>> >> its own osabi setting/name, then I don't see why we couldn't start by
>> >> adding the osabi setting as soon as we have a use for it, even if
>> >> the larger Linux Kernel patches aren't ready yet.
>> >
>> > Following on from the above, for aarch64-linux-tdep we can apply domain
>> > knowledge regarding how things are configured. Here we know that TTBR0
>> > is guaranteed to have top byte ignore set, TTBR1 does not *and* we
>> > also know (from memory-layout.txt) that TTBR0 is sufficiently small
>> > that bit 55 can be used to discriminate between the two cases.
>> >
>> > In others words regardless of whether we are running at EL0 or EL1 then
>> > I think we should mask the top byte from pointers if and only if bit 55
>> > is unset, otherwise leave them as they are.
>>
>> What I am understanding here is that you are basing your decision on
>> the fact that:
>>
>> "User addresses have bits 63:48 set to 0 while the kernel addresses have
>> the same bits set to 1. TTBRx selection is given by bit 63 of the
>> virtual address."
>>
>> Sounds legitimate for now but are we ever going to use more than
>> 48-bit virtual addresses in arm64 linux?
>
> Almost guaranteed I would have thought!
>
> However since the suggestion is *not* based on the assumption that bits
> 63:48 are zero then I don't think this matters.
>
> It is based on the assumption that bits 63:56 are unknown and cannot be
> used for decision making (because tag 0xff is not reserved) and also
> that bit 55 is not part of the VA. Bits 54:48 are not involved at all.
>
> For 52-bit VAs (and any other number of bits <56) the hueristic remains
> correct.
>
> For 56-bit VAs the pointer tagging feature cannot survive without being
> changed because with bit 55 allocated there would be no way for the
> hardware to discriminate between TTBR0 and TTBR1 pointers either. Thus
> whilst I don't deny the possibility that 56-bit addresses may eventually
> happen, *any* implementation of pointer tagging support in gdb would
> need to be updated at that point anyway.

Above discussion seems to have sufficient points in favor of using bit
55 as the indicator bit for pointer tagging on osabi Linux.
While we should also remove tagging support from non linux osabi.

Lets wait for a final agreement from Pedro on this.

>
>
> Daniel.

  reply	other threads:[~2018-04-26  8:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08 10:04 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 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
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 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 [this message]
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=CANW4E-1c8Ck_4Y52Avi1emJij90q9g8BiSvNQp4dKkdWkQonqw@mail.gmail.com \
    --to=omair.javaid@linaro.org \
    --cc=daniel.thompson@linaro.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=qiyaoltc@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).