From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41136 invoked by alias); 24 Apr 2018 15:44:56 -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 41110 invoked by uid 89); 24 Apr 2018 15:44:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f177.google.com Received: from mail-wr0-f177.google.com (HELO mail-wr0-f177.google.com) (209.85.128.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Apr 2018 15:44:50 +0000 Received: by mail-wr0-f177.google.com with SMTP id c14-v6so10320858wrd.4 for ; Tue, 24 Apr 2018 08:44:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lD+JvF/gdgCcdjOf4Xpr0//EYWBq8KM1vBXYn4nsy4Y=; b=nXgEgG7kGc3JYBfPxandHTtkAVNxF1RQe/wjEKMccw1BR9wj8S3ahZf/PZHHcJ8lKp CferKVBJXxKNrp9A7SdBeE+t7WOtpKYWh0POJdZhlv0u2ye6NXg7s+bILjrlZVvTQxHp GkLa64QmNujvkdGvGfvuax6RBvAjc+xMxpIqMQ7+E7pVbWzRXTNDJVlGqBr0W/ySpcKK ZOQ26gKkXxnxhdNZmDcoI3am2xsiIO25XFWRJ0Kj0MVX2kesPrNFnBYpHlXwsNNABQnv 4FAu8Q+fhUv82ZcZfdb4RzB02j8p35tF7wmKySe5bEGKYnhDUkneLVquagLcrdnvfOeR GrjQ== X-Gm-Message-State: ALQs6tBvbDbbAshjRoynE2obSt2dEsDM7HcUqPHInThJpqSOHRHi/BWp rvT8QQmmljSVE8qie+i39z8WNQ== X-Google-Smtp-Source: AIpwx49oIp9HI15vfdps59pl4RVv7pAtDwNn5O37Ylqu1KxxKHtXizZMWKQEJzNKHLoIqgTlLsw6Gg== X-Received: by 2002:adf:dd4f:: with SMTP id u15-v6mr17702216wrm.43.1524584688306; Tue, 24 Apr 2018 08:44:48 -0700 (PDT) Received: from holly.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id c124sm11708735wmd.36.2018.04.24.08.44.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Apr 2018 08:44:47 -0700 (PDT) Date: Tue, 24 Apr 2018 15:44:00 -0000 From: Daniel Thompson To: Pedro Alves Cc: Omair Javaid , Yao Qi , GDB Patches Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer Message-ID: <20180424154444.iotyh67w4sb7lu7j@holly.lan> References: <5e21c13b-9261-f947-e06c-dad9568278bf@redhat.com> <061e956c-72a7-2c2e-512b-3dfe42881818@redhat.com> <56373ed6-3a63-4508-61fa-54a3a456d785@redhat.com> <45f45c80-1d25-dae7-1659-2545c0eaae51@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45f45c80-1d25-dae7-1659-2545c0eaae51@redhat.com> User-Agent: NeoMutt/20180323 X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00474.txt.bz2 On Tue, Apr 24, 2018 at 12:39:15PM +0100, Pedro Alves wrote: > On 04/23/2018 08:50 AM, Omair Javaid wrote: > > On 20 April 2018 at 21:13, Daniel Thompson wrote: > > >> Perhaps a dumb question but could gdb be persuaded to mask the pointers at a lower level. > >> > >> The current patches end up masking the pointer tags relatively early, which 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 this would behave much more like the real hardware and would make debugging Linux kernel mode entirely transparent (since you cannot ptrace() kernel memory 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. > > It seems like you are proposing going back to what was originally > proposed in v1. I think these urls link through all of the > history: > > v1: > https://sourceware.org/ml/gdb-patches/2017-10/msg00593.html > v2: > https://sourceware.org/ml/gdb-patches/2017-10/msg00792.html > v3: > https://sourceware.org/ml/gdb-patches/2017-12/msg00159.html > > As can be seen in v2, as soon we started considering watchpoints, > here: > https://sourceware.org/ml/gdb-patches/2017-10/msg00793.html > the gdb core needed to be made aware of tagged pointers, the bit > masking could no longer be deferred to the lower level ptrace calls > alone. And then given that the core of gdb needs to know to > mask out tagged address, by v3, we had no masking at the ptrace > level anymore. So I'm not sure how that would work; we'd need > a more detailed proposal. Thanks for the links. If you've been round this loop once before I don't think I want to encourage anyone to go round it again. Daniel.