[PATCH 0/3 v3] [AArch64] Support tagged pointer

[Omair Javaid]

On 11 April 2018 at 16:19, Pedro Alves <palves@redhat.com> wrote:

> On 04/11/2018 12:12 PM, Omair Javaid wrote:
> > On 11 April 2018 at 15:13, Pedro Alves <palves@redhat.com <mailto:
> palves@redhat.com>> wrote:
> >
> >     On 04/11/2018 01:15 AM, Omair Javaid wrote:
> >
> >     > This patch has broken kernel debugging using kgdb and openOCD.
> >
> >     OOC, can you qualify this a bit more, please?
> >
> >     Does the kernel use the high bits for something?
> >
> >
> > We can safely assume that top byte is 0 in case of user address space on
> linux because it enables tagging support but not for kernel address space.
> >
> > According to linux memory layout of AArch64 given here:
> https://www.kernel.org/doc/Documentation/arm64/memory.txt
> >
> > "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."
>
> Ah, that's clear as day now.
>
> >
> > According to kernel document on tagged pointer support in AArch64 given
> here: https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt
> >
> > The kernel configures the translation tables so that translations made
> > via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
> > the virtual address ignored by the translation hardware. This frees up
> > this byte for application use.
> >
> > With set_gdbarch_significant_addr_bit applied to aarch64-tdep following
> happens when gdb tries reading kernel address space memory:
> >
> > query the 0xffffffc000092698 memory data, GDB sent "m00ffffc000092698,4"
> instead of "mffffffc000092698,4"
> >
> OK, that makes a lot more sense now.  The above is the perfect
> info to be included in a git commit log.  Want to submit a patch?
>

Yes I can submit a patch that enables set_gdbarch_significant_addr_bit for
aarch64-linux-tdep only.

But a point to discuss here is the use-case where some people use
*-linux-gdb for debugging seamlessly between kernel and user-space.

There can be ways we can distinguish between user/kernel address space and
clear or set top byte of the address even in case of linux targets.

Does this sound something we should do?


>
> Thanks,
> Pedro Alves
>