Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] [AArch64 Linux] Get rid of top byte from tagged address
Date: Thu, 19 Oct 2017 09:52:00 -0000	[thread overview]
Message-ID: <561ea277-4b4c-ae82-01e1-1cde96cb54f2@redhat.com> (raw)
In-Reply-To: <1508400527-20718-1-git-send-email-yao.qi@linaro.org>

On 10/19/2017 09:08 AM, Yao Qi wrote:
> ARMv8 supports tagged address, that is, the top one byte in address
> is ignored.  It is always enabled on aarch64-linux.

In that case, why isn't the kernel itself stripping the top byte?

OK, looking around, I found:

 https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt

where it's documented that the top byte must be 0 when calling
into the kernel.

Having this reference in the log is helpful.

> The patch clear
> the top byte of the virtual address, at the point before GDB/GDBserver
> pass the address to /proc or ptrace syscall.  The top byte of address is
> still retained in the rest of GDB, because these bits can be used by
> different applications in different ways.  That is reason I didn't
> implement gdbarch method addr_bits_remove to get rid of them.

I'm fine with doing this if it's what arm/linaro folks want,
though personally (with absolutely no experience in this) I have
reservations about whether stripping the top byte in the special
case of memory accesses is a good idea, since it may puzzle folks
when they pass such pointers/addresses in registers/structures and
things don't magically work then (and then gdb masks the problem when
folks try to diagnose it, as in "but I can access the object
via "p *s->ptr", why isn't this working???  bad gdb.").

So I think this should be documented in the manual somewhere.

> Before this patch,
> (gdb) x/x 0x0000000000411030
> 0x411030 <global>:	0x00000000
> (gdb) x/x 0xf000000000411030
> 0xf000000000411030:	Cannot access memory at address 0xf000000000411030
> 
> After this patch,
> 
> (gdb) x/x 0x0000000000411030
> 0x411030 <global>:	0x00000000
> (gdb) x/x 0xf000000000411030
> 0xf000000000411030:	0x00000000

I think we should have a testsuite test for this.
Could be something like the above (though I'd suggest making
that 'global' variable have some value other than 0s to make
sure we're reading the right memory).

And/or something like:

  uint32_t global = 0x11223344;

  gdb_test "p *(uint32_t *) (((uintptr_t) 0xf << 60) | (uintptr_t) &global) == global" \
    " = 1" \
    "top byte ignored"

> +  if (object == TARGET_OBJECT_MEMORY)
> +    {
> +      /* ARMv8 supports tagged address, that is, the top one byte in
> +	 virtual address is ignored.  */
> +      offset = offset & 0x0fffffffffffffffULL;

In several places, instead of:
   V = V & MASK;
you can write:
   V &= MASK;
i.e here, write instead:
   offset &= 0x0fffffffffffffffULL;
which is I think more usual.

Thanks,
Pedro Alves


  parent reply	other threads:[~2017-10-19  9:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19  8:08 Yao Qi
2017-10-19  9:51 ` Ramana Radhakrishnan
2017-10-19 10:53   ` Yao Qi
2017-10-19  9:52 ` Pedro Alves [this message]
2017-10-19  9:55   ` Ramana Radhakrishnan
2017-10-19 10:51   ` Yao Qi
2017-10-19 11:09     ` Pedro Alves
2017-10-19 13:17       ` Yao Qi
2017-10-19 13:22         ` Pedro Alves
2017-10-19 11:21 ` Pedro Alves
2017-10-19 13:25   ` Yao Qi

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=561ea277-4b4c-ae82-01e1-1cde96cb54f2@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --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