This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] [AArch64 Linux] Get rid of top byte from tagged address
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 19 Oct 2017 12:08:59 +0100
- Subject: Re: [PATCH] [AArch64 Linux] Get rid of top byte from tagged address
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6E3D17F7A9
- References: <1508400527-20718-1-git-send-email-yao.qi@linaro.org> <561ea277-4b4c-ae82-01e1-1cde96cb54f2@redhat.com> <86po9jv29n.fsf@gmail.com>
> Pedro Alves <palves@redhat.com> writes:
>
>> 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.
>
> I don't understand how does GDB affect the program. ARMv8 architecture
> supports tagged address for data values, and top byte of virtual address
> is ignored in some cases,
I didn't say that GDB affects the program. From the kernel document:
~~~
All interpretation of userspace memory addresses by the kernel assumes
an address tag of 0x00.
This includes, but is not limited to, addresses found in:
- pointer arguments to system calls, including pointers in structures
passed to system calls,
~~~
This means with something like:
#define tagptr(PTR) \
((typeof (PTR)) ((uintptr_t) (PTR) | 0xf000000000000000ULL))
strcat (buf, "hello\n");
char *ptr = tagptr(buf); // assume this is hidden from view.
write (1, ptr, 6); // kernel rejects this.
and then the user might be puzzled because stepping through
that code:
(gdb) print ptr
(gdb) print ptr[0]
etc. works without error.
Same with iovec/readv, ioctl, etc., any system call that takes
a pointer argument.
Thanks,
Pedro Alves