From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59738 invoked by alias); 1 May 2018 15:02:16 -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 59659 invoked by uid 89); 1 May 2018 15:02:15 -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=According, Hx-spam-relays-external:74.125.82.67, H*RU:74.125.82.67, HX-Envelope-From:sk:daniel. X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 May 2018 15:02:12 +0000 Received: by mail-wm0-f67.google.com with SMTP id j5so19479155wme.5 for ; Tue, 01 May 2018 08:02:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WcyCj3mu3Yerz2zfnGeP7IcFt848qT0P0X3hzRgQcOA=; b=U6KlH0qijqs8Uy7euO8RF+2TCQagZjL8m8gDzvTCjh8c6mhNVQeGE/mVyuSdEpmPqi 03/njmJQFYxFSyg+ozjfLHDMz24n3ZK4FdhoVXXssHDwiPlVTt7Jmq/zMZJzskOMEWxX Wy9TF65rGyrjjW5B9rORcfb35vR5Vgo7dgLfX4lXv3sLhcetRcKF6Y1ciBMT6xpxIieN YHmdZydOFDlx3VtNvc2joZtgEM+xk16YYQq9bEJdRi8HuwppGAGPK8gFcZGtKJybAhSo Pn0L+B2ELDQIiHSh/Lmnj3eshSHITlFFOomxUXhKm2MGk9y7YMCb4Zt+iI/6NC6jdCbr EkpA== X-Gm-Message-State: ALQs6tCsii/WkNahqgGUtdP/thLlhUNF7izzJRr4XcR9eZJG8sPW8Ttv PPsnY0mRy1Eiw/0bU0/QnyCZDcpL2RY= X-Google-Smtp-Source: AB8JxZroi/yfDQtSHeKsv4XRAcfL1StzlL4qtDBrNpzWJuJ8qaJ6svy50TivhMIg57SyAX2+vqvMCg== X-Received: by 10.28.22.140 with SMTP id 134mr8020300wmw.53.1525186929158; Tue, 01 May 2018 08:02:09 -0700 (PDT) Received: from holly.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.googlemail.com with ESMTPSA id o12-v6sm9514522wri.78.2018.05.01.08.02.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 08:02:08 -0700 (PDT) Subject: Re: [PATCH] [PR gdb/23127] [AArch64] Fix tagged pointer support To: gdb-patches@sourceware.org References: <1525138292-4526-1-git-send-email-omair.javaid@linaro.org> From: Daniel Thompson Message-ID: <459efa20-8a17-e3c2-f1fc-2f1a72ed9140@linaro.org> Date: Tue, 01 May 2018 15:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1525138292-4526-1-git-send-email-omair.javaid@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00005.txt.bz2 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; > } >