From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18748 invoked by alias); 11 Apr 2018 12:01:04 -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 13104 invoked by uid 89); 11 Apr 2018 12:00:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:alternative X-HELO: mail-qt0-f177.google.com Received: from mail-qt0-f177.google.com (HELO mail-qt0-f177.google.com) (209.85.216.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Apr 2018 12:00:30 +0000 Received: by mail-qt0-f177.google.com with SMTP id w23so1554809qtn.3 for ; Wed, 11 Apr 2018 05:00:25 -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=+YQrBAcv25i2zXV929ric8GcwItn3wQeI39fMUomyzY=; b=JpJEIb9ZYfP/Ho5VAGWhDQ4EV0x8oESApgrl4IG8Ve84AxyXvw1v9nGe7nfZ7r6HCL wtx5uNTIIOqAOJyW4Xd3v8Ye+Ts1cB0/0vgrT1oVs6088yvSV24Qsjg5FX5A6VRdDXxV Z1JzwakCcPwBxplSBgQsTa6T0teQiCybCiwHzSDdq/p5Z+uylM7+0htbdVx3PgKqCebX nqnapjVzuHh84vU4nmZL7l+sFXQ+52cRvNI3i4BrCg1QiuASKUBEvgH/DLWykNo1LtOK WcKLnt9ZjOkHi6NrbI0b73HYZ5T11+y3oSJwJr9WKTc4W+K0u5dBFUClWc0Kn5mdBogh WkIQ== X-Gm-Message-State: ALQs6tCtpNz5cNDSmbSnGg9Fdlk9pM6dNve33FQNn22C+noNf73JxZc9 mbe39LKd/xkAFa5boDLj+xXuhUrdEM1kF3DI3ye0kw== X-Google-Smtp-Source: AIpwx48gtw90CJoiWowkAD+r7VdpklCQ/YIaEYSB6u/7ajNu0CIhird0+rxWjy1RJ96wnmfUB2sL2940v3vFVUC4Mdk= X-Received: by 10.200.67.78 with SMTP id a14mr6836900qtn.18.1523448023572; Wed, 11 Apr 2018 05:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.60.210 with HTTP; Wed, 11 Apr 2018 04:59:53 -0700 (PDT) In-Reply-To: <5e21c13b-9261-f947-e06c-dad9568278bf@redhat.com> References: <1512727471-30745-1-git-send-email-yao.qi@linaro.org> <5429b7f0-ee91-67f4-3b15-f5de9aa06389@redhat.com> <5e21c13b-9261-f947-e06c-dad9568278bf@redhat.com> From: Omair Javaid Date: Wed, 11 Apr 2018 12:01:00 -0000 Message-ID: Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Pedro Alves Cc: Yao Qi , GDB Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00214.txt.bz2 On 11 April 2018 at 16:19, Pedro Alves wrote: > On 04/11/2018 12:12 PM, Omair Javaid wrote: > > On 11 April 2018 at 15:13, Pedro Alves palves@redhat.com>> wrote: > > > > On 04/11/2018 01:15 AM, Omair Javaid wrote: > > > > > This patch has broken kernel debugging using kgdb and openOCD. > > > > OOC, can you qualify this a bit more, please? > > > > Does the kernel use the high bits for something? > > > > > > We can safely assume that top byte is 0 in case of user address space on > linux because it enables tagging support but not for kernel address space. > > > > According to linux memory layout of AArch64 given here: > 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. TTBRx selection is given by bit 63 of the > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > virtual address." > > Ah, that's clear as day now. > > > > > According to kernel document on tagged pointer support in AArch64 given > here: 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. > > > > With set_gdbarch_significant_addr_bit applied to aarch64-tdep following > happens when gdb tries reading kernel address space memory: > > > > query the 0xffffffc000092698 memory data, GDB sent "m00ffffc000092698,4" > instead of "mffffffc000092698,4" > > > OK, that makes a lot more sense now. The above is the perfect > info to be included in a git commit log. Want to submit a patch? > Yes I can submit a patch that enables set_gdbarch_significant_addr_bit for aarch64-linux-tdep only. But a point to discuss here is the use-case where some people use *-linux-gdb for debugging seamlessly between kernel and user-space. There can be ways we can distinguish between user/kernel address space and clear or set top byte of the address even in case of linux targets. Does this sound something we should do? > > Thanks, > Pedro Alves >