From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16785 invoked by alias); 23 Apr 2018 07:50:40 -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 16775 invoked by uid 89); 23 Apr 2018 07:50:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Thompson, thompson, relatively, HX-Received:Mon 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; Mon, 23 Apr 2018 07:50:37 +0000 Received: by mail-qt0-f195.google.com with SMTP id j26-v6so16603514qtl.11 for ; Mon, 23 Apr 2018 00:50:37 -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:content-transfer-encoding; bh=kBEYHrSqfG6O5sD1euifpmzQKSon+4puWGAm0S7Lklc=; b=JtHabMyUhwirwu13aGjHl7w0RKYyJStfw8iDluH/6MG4jUzNfSNzxWyUKZRJQSGqM9 xgmS5WcIBEJ4k0XYUd0xznEadjVxHURSzj+Kib6iECgaD5clEx0jTk5i9+Cxa9VKru9e Ak30Igmp5O2neQcTZ6/31jHDjNdO+ly6yr/f8nJZCBcV7LF32+6jCNM8CKaQSueVI7os w9HKVov06oaMGkrCPby3G3kHq6/F2EDl3Nw5wiyQd2AfrwcsbHuLADSAvrFrGuTMfuyd e8vTVhqEb4ndHP6CZXwZTFmZNfLmTwLr7ykjzk7KnZenCqT5YpDS4+tMIVorsYL1V9oM kcKA== X-Gm-Message-State: ALQs6tDrhro5MeudDdOBhI/Q99M5FHD9Jf/DdoCVenxsfPFSH0CxTDIN bjWeyoAMvoLgUhD1nZSR+Q9GwCA9b9tVQRW1LCyBoQ== X-Google-Smtp-Source: AIpwx49gdwCKJiyePCCBRXa/aAWnMfYiel/3sDgj8rsM03l3+sVxCK9uuyxGbi+iuKth01e98VbmpwMfNr127iIxrVY= X-Received: by 2002:ac8:4293:: with SMTP id o19-v6mr22311829qtl.321.1524469835860; Mon, 23 Apr 2018 00:50:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.67.82 with HTTP; Mon, 23 Apr 2018 00:50:05 -0700 (PDT) In-Reply-To: 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> <061e956c-72a7-2c2e-512b-3dfe42881818@redhat.com> <56373ed6-3a63-4508-61fa-54a3a456d785@redhat.com> From: Omair Javaid Date: Mon, 23 Apr 2018 07:50:00 -0000 Message-ID: Subject: Re: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Daniel Thompson Cc: Pedro Alves , Yao Qi , GDB Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00443.txt.bz2 On 20 April 2018 at 21:13, Daniel Thompson wro= te: > > On 20/04/18 15:33, Omair Javaid wrote: >> >> On 17 April 2018 at 03:57, Pedro Alves wrote: >> >>> On 04/16/2018 02:36 AM, Omair Javaid wrote: >>>> >>>> On 11 April 2018 at 23:27, Pedro Alves wrote: >>>> >>>>> On 04/11/2018 12:59 PM, Omair Javaid wrote: >>>>> >>>>>> Yes I can submit a patch that enables set_gdbarch_significant_addr_b= it >>>>> >>>>> 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 spa= ce >>>>> >>>>> and clear or set top byte of the address even in case of linux target= s. >>>>>> >>>>>> >>>>>> Does this sound something we should do? >>>>> >>>>> >>>>> Yeah, why not. >>>>> >>>>> What are the pending kernel debugging patches using to distinguish >>>>> userspace and kernel debugging modes? Off hand, I'd think we'd want = to >>>>> make those separate ABIs / osabis / gdbarchs. >>>>> >>>> >>>> Sorry for late reply on this I am out of office this week. >>>> >>>> I have given this a thought and I propose to do the following: >>>> >>>> Turn on pointer tagging on OSABI (LINUX) by default. >>>> >>>> Add commands set aarch64 pointer-tagging show/enable/disable. >>>> >>>> Once LKD patches for aarch64/arm land in our need for this will >>>> automatically be solved. >>> >>> >>> Makes sense, but I'd like to clarify usefulness of the separate >>> "set aarch64 pointer-tagging" command. >>> If indeed we're doing to end up with a separate osabi for the Linux >>> kernel, then "set osabi linux-kernel" will result >>> in disabling pointer-tagging too. So, will it still be useful to have >>> the specific "set aarch64 pointer-tagging" commands? Do you see >>> use cases for "set aarch64 pointer-tagging" beyond disabling it >>> for Linux kernel debugging? I'm thinking that it may be useful >>> for bare metal debugging. But, ideally, GDB would figure it out >>> on its own without user intervention. Is there's some bit in some >>> register gdb could read that indicates whether tagging is enabled? >>> >>> >> Pointer tagging information is stored in MMU registers so in linux >> user-space we cannot actually read if pointer tagging is enabled or not >> based on register bits. >> JTAG debuggers should be able to read MMU registers and know whether >> pointer tagging is enabled or not. > > > Perhaps a dumb question but could gdb be persuaded to mask the pointers a= t a lower level. > > The current patches end up masking the pointer tags relatively early, whi= ch results in masked pointers being sent via the gdb remote protocol (which= is what causes some of the problems at present: kgdb and OpenOCD get asked= for the wrong pointer). > > If the pointers were masked as the arguments to ptrace() were marshaled t= his would behave much more like the real hardware and would make debugging = Linux kernel mode entirely transparent (since you cannot ptrace() kernel me= mory we would never try masking out the tag). Although this can be done with a hook but will require some fundamental changes to the way ptrace inf_ptrace_xfer_partial memory accesses routines are written. Currently we use a generic implementation inf_ptrace_xfer_partial for all target architectures. Same is the case with GDBServer it just handles the ptrace calls except in a few cases where we need extra architecture specific code before ptrace call like setting hardware breakpoints watchpoints etc. As top byte in tagged address is essentially data, pushing masking down to gdbserver will mean that we ll be sending out data mangled as part of the address. Passing mangled address over RSP expecting other side will correct it doesnt sound right. Lets see what Pedro has to see on this. > > More generally masking would become the problem of the register read code= for the target. I suspect many JTAG debuggers would (and certainly should)= already work correctly as their register reads can honour the TTBR0 status. > > > Daniel.