This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [AArch64 Linux] Get rid of top byte from tagged address


On 10/19/17 10:52 AM, Pedro Alves wrote:
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.").

Yeah that thought crossed my mind too whether it makes a better debug experience keeping the top byte in the debug view but only stripping it off in the ptrace interface or wherever you have to respect the kernel interface.


regards
Ramana


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]