This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/3] [AArch64 Linux] Get rid of top byte from tagged address on memory access
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Thu, 9 Nov 2017 20:24:24 +0000
- Subject: Re: [PATCH 1/3] [AArch64 Linux] Get rid of top byte from tagged address on memory access
- Authentication-results: sourceware.org; auth=none
- References: <1509006590-9401-1-git-send-email-yao.qi@linaro.org> <1509006590-9401-2-git-send-email-yao.qi@linaro.org>
Hi Yao,
On 10/26/2017 09:29 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. See
> https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt
>
> The patch clear the top byte of the virtual address, at the point before
> GDB/GDBserver pass the address to /proc or ptrace syscall on memory access.
> 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.
>
> 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
>
> With the tagged address, the variables/memory can be access via different
> addresses (or tags), but GDB uses cache for stack variable access and code
> access to speed up remote debugging. Fortunately, tagged address and
> GDB stack/code cache can coexist, because,
>
> - 'x' command doesn't go through cache, so we don't have to worry,
> - gdb only uses stack cache when it believes the variable is on stack,
>
> int i;
> int *p = &i;
>
> when print 'i' or 'p', gdb uses stack caches, but when print '*p', gdb
> only uses stack caches to get 'p', and get '*p' without cache, because
> gdb doesn't know the address p points to is on stack or not.
That sounds a bit fragile to me...
> - gdb uses code caches to access code, do disassembly for example, when
> gdb does disassembly for a function (without tag) and a tagged function
> pointer, gdb creates thinks they are different addresses, and creates
> two different cache lines, but we only have cache when inferior stops,
> and code caches are regarded read-only.
I don't understand the second point, the one about the code cache.
The tail end of raw_memory_xfer_partial writes through the code cache:
if (writebuf != NULL
&& !ptid_equal (inferior_ptid, null_ptid)
&& target_dcache_init_p ()
&& (stack_cache_enabled_p () || code_cache_enabled_p ()))
{
DCACHE *dcache = target_dcache_get ();
/* Note that writing to an area of memory which wasn't present
in the cache doesn't cause it to be loaded in. */
dcache_update (dcache, res, memaddr, writebuf, *xfered_len);
}
> +++ b/gdb/testsuite/gdb.arch/aarch64-tagged-pointer.exp
> @@ -0,0 +1,68 @@
> +# Copyright 2017 Free Software Foundation, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software
> +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
We shouldn't be using this old snail mail address header anymore.
If we still have any, they should be converted to the newer one
with the URL instead.
Thanks,
Pedro Alves