The patch at: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=a738ea1d41daeec0cccb4ab6671f4f6d53bd9e18 .. incorrectly assumes that GDB for AArch64 is only ever going to be used for memory accesses via TTBR0. The patch ends up zeroing the top byte for high virtual addresses that are translated via TTBR1. This makes GDB unusable for debugging typical OS kernels etc. I understand from some offline discussions that a key part of the problem is that establishing the state of the top-byte-ignore control bits (TCR.TBI0 and TCR.TBI1 for TTBR0 and TTBR1 respectively) is currently not possible with GDB. I'm filing this bug as a matter of record in the hope that it saves someone some bother and that it may be addressed by the experts in an architecturally clean way.
This is reproducible on GCC 8.1
Robin Randhawa: Just curious. Do you see a need to turn off top byte ignore on aarch64-linux-gdb? We can turn it off for aarch64-none-elf-gdb.. ?
Thanks for responding. As it happens, I hit this because I was debugging some bespoke low level MMU init code and happened to use aarch64-linux-gdb. So just so I understand better, at the moment, using aarch64-linux-gdb with qemu-system-aarch64 (virt machine) I see: $ gdb GNU gdb (GDB) 8.1.50.20180430-git [...] (gdb) target remote localhost:1234 Remote debugging using localhost:1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x0000000040000000 in ?? () (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0xffff000008a68c3c in ?? () (gdb) set debug remote 1 (gdb) x 0xffff000008a68c3c 0xffff000008a68c3c: Sending packet: $mff000008a68c3c,4#89...Ack Packet received: E14 Cannot access memory at address 0xffff000008a68c3c Are you suggesting that using aarch64-none-elf-gdb for this example would work ? That's interesting.
This patch fixes the issue. https://sourceware.org/ml/gdb-patches/2018-05/msg00000.html
Adding 8.1.1 as the target milestone for tracking purposes, as the patch was approved for the branch.
The master branch has been updated by Omair Javaid <omjavaid@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8727de56b0dbe25b7b4a3bd04f72ac41992463ed commit 8727de56b0dbe25b7b4a3bd04f72ac41992463ed Author: Omair Javaid <omair.javaid@linaro.org> Date: Tue May 1 06:31:32 2018 +0500 Fix tagged pointer support This patch fixes tagged pointer support for AArch64 GDB. Linux kernel debugging failure was reported after tagged pointer support was committed. After a discussion around best path forward to manage tagged pointers on GDB side we are going to disable tagged pointers support for aarch64-none-elf-gdb because for non-linux applications we cant be sure if tagged pointers will be used by MMU or not. Also for aarch64-linux-gdb we are going to sign extend user-space address after clearing tag bits. This will help debug both kernel and user-space addresses based on information from linux kernel documentation given below: According to AArch64 memory map: 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." According to AArch64 tagged pointers document: 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. Running gdb testsuite after applying this patch introduces no regressions and tagged pointer test cases still pass. gdb/ChangeLog: 2018-05-10 Omair Javaid <omair.javaid@linaro.org> PR gdb/23127 * aarch64-linux-tdep.c (aarch64_linux_init_abi): Add call to set_gdbarch_significant_addr_bit. * aarch64-tdep.c (aarch64_gdbarch_init): Remove call to set_gdbarch_significant_addr_bit. * utils.c (address_significant): Update to sign extend addr.
The gdb-8.1-branch branch has been updated by Omair Javaid <omjavaid@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8a620990c7634e872b31718a8411a90a6f384457 commit 8a620990c7634e872b31718a8411a90a6f384457 Author: Omair Javaid <omair.javaid@linaro.org> Date: Tue May 1 06:31:32 2018 +0500 Fix tagged pointer support This patch fixes tagged pointer support for AArch64 GDB. Linux kernel debugging failure was reported after tagged pointer support was committed. After a discussion around best path forward to manage tagged pointers on GDB side we are going to disable tagged pointers support for aarch64-none-elf-gdb because for non-linux applications we cant be sure if tagged pointers will be used by MMU or not. Also for aarch64-linux-gdb we are going to sign extend user-space address after clearing tag bits. This will help debug both kernel and user-space addresses based on information from linux kernel documentation given below: According to AArch64 memory map: 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." According to AArch64 tagged pointers document: 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. Running gdb testsuite after applying this patch introduces no regressions and tagged pointer test cases still pass. gdb/ChangeLog: 2018-05-10 Omair Javaid <omair.javaid@linaro.org> PR gdb/23127 * aarch64-linux-tdep.c (aarch64_linux_init_abi): Add call to set_gdbarch_significant_addr_bit. * aarch64-tdep.c (aarch64_gdbarch_init): Remove call to set_gdbarch_significant_addr_bit. * utils.c (address_significant): Update to sign extend addr.
Can we close this PR, now?
(In reply to Joel Brobecker from comment #8) > Can we close this PR, now? My use-case that required using TTBR1 accesses for high VAs passes with Omair's fix so +1 for closing from my side FWIW. As an aside: It would have been good to reference this bug in Omair's commit log for completeness. Thanks all.
THis is fixed. Bug PR in change log.