From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128403 invoked by alias); 24 Apr 2018 11:39:22 -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 128354 invoked by uid 89); 24 Apr 2018 11:39:19 -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,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Apr 2018 11:39:18 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9D26D81A88C4; Tue, 24 Apr 2018 11:39:16 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id D39252166BC6; Tue, 24 Apr 2018 11:39:15 +0000 (UTC) Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Omair Javaid , Daniel Thompson 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> Cc: Yao Qi , GDB Patches From: Pedro Alves Message-ID: <45f45c80-1d25-dae7-1659-2545c0eaae51@redhat.com> Date: Tue, 24 Apr 2018 11:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00458.txt.bz2 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, Pedro Alves