From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118727 invoked by alias); 8 May 2018 09:32:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 118708 invoked by uid 89); 8 May 2018 09:32:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=panic, kicked, utils.c, UD:utils.c X-HELO: mail-qt0-f195.google.com Received: from mail-qt0-f195.google.com (HELO mail-qt0-f195.google.com) (209.85.216.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 May 2018 09:32:00 +0000 Received: by mail-qt0-f195.google.com with SMTP id m16-v6so40061060qtg.13 for ; Tue, 08 May 2018 02:32:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=77VFTg/X8qRNJe9rGuuc+PaXzeAKHegdXgga+N/ZGeQ=; b=qZf+e0Ee5oK1HFFkSoC4RapdhuEFtZNYnxVx1jHp9siE7RCcre/cRyRCs5ZLXJUS3f zcUogxAgLNvjX8MnweggNfopTScbtSqPBB+eDCrzkF5x5KDaoq1LYXdNtM2TjbTKuIT/ CW9rLv45zSowlFbnm56vHaD4Lfv6Nsms5kc3XkxDTolTipTGb0/VhrAZnuZndBp8YgxJ ufGpTceJkBOKUeaE2uEAHk6/jGt8LISiPIcTrtZZ3AQdKVFF+wngZ1kaBOZYSuv6TjoR AgRsk/kB4v4IoIhWLpR3NBR9efG0xih1Giw3dkzxd2QdXAm20YPwVms1aGV1H+kL9rYE XqnA== X-Gm-Message-State: ALQs6tBFFaDPkF0G8HTcoxondkMQtlM477lUj3SqYg3LHU/qjBZWs96i crurSOot775m+xil85noCMl/WkHhC43uRH3uIi7cpQ== X-Google-Smtp-Source: AB8JxZrsRxScBk8KR4Xe84yNUAbcwJNmXmaFoYyvQ6j99Saw7c88v1bN96XNe0sxiPAOC7jkdO3OuxGs7M4WNOA7jEk= X-Received: by 2002:ac8:19c2:: with SMTP id s2-v6mr35323363qtk.384.1525771918420; Tue, 08 May 2018 02:31:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.24.85 with HTTP; Tue, 8 May 2018 02:31:28 -0700 (PDT) In-Reply-To: <459efa20-8a17-e3c2-f1fc-2f1a72ed9140@linaro.org> References: <1525138292-4526-1-git-send-email-omair.javaid@linaro.org> <459efa20-8a17-e3c2-f1fc-2f1a72ed9140@linaro.org> From: Omair Javaid Date: Tue, 08 May 2018 09:32:00 -0000 Message-ID: Subject: Re: [PATCH] [PR gdb/23127] [AArch64] Fix tagged pointer support To: Daniel Thompson , Pedro Alves Cc: GDB Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00180.txt.bz2 On 1 May 2018 at 20:02, Daniel Thompson wrote: > On 01/05/18 02:31, Omair Javaid wrote: >> >> 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 us 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. > > > ... and I kicked the tyres a little bit using kgdb. > > print worked as expected, backtrace no longer provokes a gdb panic and > breakpoints work (albeit for rather approximate definition of work... and > the need for approximation is not gdb's fault). > > > Daniel. > > > >> gdb/ChangeLog: >> 2018-05-01 Omair Javaid >> >> * 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. >> --- >> gdb/aarch64-linux-tdep.c | 5 +++++ >> gdb/aarch64-tdep.c | 5 ----- >> gdb/utils.c | 14 +++++++++----- >> 3 files changed, 14 insertions(+), 10 deletions(-) >> >> diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c >> index 1f3e888..ba5757d 100644 >> --- a/gdb/aarch64-linux-tdep.c >> +++ b/gdb/aarch64-linux-tdep.c >> @@ -1062,6 +1062,11 @@ aarch64_linux_init_abi (struct gdbarch_info info, >> struct gdbarch *gdbarch) >> /* Syscall record. */ >> tdep->aarch64_syscall_record = aarch64_linux_syscall_record; >> + /* The top byte of a user space address known as the "tag", >> + is ignored by the kernel and can be regarded as additional >> + data associated with the address. */ >> + set_gdbarch_significant_addr_bit (gdbarch, 56); >> + >> /* Initialize the aarch64_linux_record_tdep. */ >> /* These values are the size of the type that will be used in a system >> call. They are obtained from Linux Kernel source. */ >> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c >> index 01566b4..3c1f389 100644 >> --- a/gdb/aarch64-tdep.c >> +++ b/gdb/aarch64-tdep.c >> @@ -2972,11 +2972,6 @@ aarch64_gdbarch_init (struct gdbarch_info info, >> struct gdbarch_list *arches) >> set_tdesc_pseudo_register_reggroup_p (gdbarch, >> >> aarch64_pseudo_register_reggroup_p); >> - /* The top byte of an address is known as the "tag" and is >> - ignored by the kernel, the hardware, etc. and can be regarded >> - as additional data associated with the address. */ >> - set_gdbarch_significant_addr_bit (gdbarch, 56); >> - >> /* ABI */ >> set_gdbarch_short_bit (gdbarch, 16); >> set_gdbarch_int_bit (gdbarch, 32); >> diff --git a/gdb/utils.c b/gdb/utils.c >> index b957b0d..1f9be8f 100644 >> --- a/gdb/utils.c >> +++ b/gdb/utils.c >> @@ -2704,14 +2704,18 @@ When set, debugging messages will be marked with >> seconds and microseconds."), >> CORE_ADDR >> address_significant (gdbarch *gdbarch, CORE_ADDR addr) >> { >> - /* Truncate address to the significant bits of a target address, >> - avoiding shifts larger or equal than the width of a CORE_ADDR. >> - The local variable ADDR_BIT stops the compiler reporting a shift >> - overflow when it won't occur. */ >> + /* Clear insignificant bits of a target address and sign extend >> resulting >> + address, avoiding shifts larger or equal than the width of a >> CORE_ADDR. >> + The local variable ADDR_BIT stops the compiler reporting a shift >> overflow >> + when it won't occur. */ >> int addr_bit = gdbarch_significant_addr_bit (gdbarch); >> if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)) >> - addr &= ((CORE_ADDR) 1 << addr_bit) - 1; >> + { >> + CORE_ADDR sign = (CORE_ADDR) 1 << (addr_bit - 1); >> + addr &= ((CORE_ADDR) 1 << addr_bit) - 1; >> + addr = (addr ^ sign) - sign; >> + } >> return addr; >> } >> > Ping! Hi Pedro, I was wondering if you can kindly help review this patch. This is a critical bug as it blocks kernel debugging on AArch64. Also can we push this to GDB 8.1.1 once it gets accepted? Thanks!