From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34134 invoked by alias); 24 Apr 2018 16:05:51 -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 34095 invoked by uid 89); 24 Apr 2018 16:05:50 -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=respective, HX-HELO:sk:mail-wm, Hx-spam-relays-external:74.125.82.68, H*RU:74.125.82.68 X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Apr 2018 16:05:43 +0000 Received: by mail-wm0-f68.google.com with SMTP id j4so2081660wme.1 for ; Tue, 24 Apr 2018 09:05:43 -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=tDtPWU4yGtSNh8INV2eI7HAQ5VXusqCH7FlFDg8hIc4=; b=IcYzWmu///rH29514Liw2DAAJZrw5U57ruVn7k+aHVQkzz0lRAkrfYeoGzDim4eaXj +XG2o4ZoLl0bQFzTjMnDdIwbk5toXvdXGWpV5FAa4TBjq3idBeNVkTL/VOh/XzSnKkte HSC/92OxPLGmCvS7sAq6vs7qZIKgcTT59flxbnEUh3sOEfa4Co37GjBGDL+HLdS7srQO PYXDffli3BbM0xmHBGB4y8E2YQq8Q/1PlpyRrXQKR/lFz1UhfYk822PfnkmYQcjEyRsg 9rO5EjtIcjZZ16GOjk5sgZw8MLRtRlai5f498lvG3+83F6Y5UoRhJl5gN9aXpp0z8Dh4 xE4Q== X-Gm-Message-State: ALQs6tCb5pE10ATGfF+p38AVl862AUytvaTrsV4je0D5nWy4ns8CtLoz BAbsjbrvWC3+Uueth+tEcVR/0A== X-Google-Smtp-Source: AIpwx4+bEJV+a06frWt0MMuHZQk8nHgI/tvuO9KDmwwDSC9W56ww8HLHO/4rRlmh2KIFxPbFoduu0A== X-Received: by 10.28.236.19 with SMTP id k19mr13050793wmh.11.1524585941676; Tue, 24 Apr 2018 09:05:41 -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 32-v6sm12731204wrf.79.2018.04.24.09.05.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Apr 2018 09:05:40 -0700 (PDT) Date: Tue, 24 Apr 2018 16:05: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: <20180424160538.kxvorrhvku4ukpj6@holly.lan> References: <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> <3f62b4ea-1f80-5faa-f372-b83b3e5de448@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f62b4ea-1f80-5faa-f372-b83b3e5de448@redhat.com> User-Agent: NeoMutt/20180323 X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00475.txt.bz2 On Tue, Apr 24, 2018 at 12:48:19PM +0100, Pedro Alves wrote: > Hi, > > On 04/20/2018 03:33 PM, Omair Javaid wrote: > > > 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. > > > > Rationale behind adding a separate command is to allow other application to > > control pointer tagging for example bare-metal (non-linux OSes) which want > > to use pointer tagging can enable it. I must admit I dont know of any such > > use-case as of now. > > Alright, that's in line with what I was thinking. Though, bare metal > should have access to MMU registers too. Ideally, things would Just Work > without user intervention. But I don't mind starting by adding a > user-controllable knob, it might be a convenient escape hatch. We can always > extend it from "on/off" -> "on/off/auto" setting, with auto the default > in future. For bare metal cases this is not a simple on/off control! Top byte ignore (a.k.a. pointer tagging) has separate on/off switches for TTBR0 (0x0 upwards) and TTBR1 (0xffffffffffff downwards) *and* we have to know the respective sizes of TTBR0 and TTBR1 to be sure which table we are using. > > Also I am not sure about the timeline of Linux Kernel patches going into > > gdb and for now I thought of this command as the most suitable option. > > Moreover some users might also be interested in combination where pointer > > tagging is enabled but Linux Kernel threads support is disabled so I > > thought we should give the control to the user in cases where we cannot > > predict use-cases. > > If everyone agrees that proper Linux kernel support benefits from > its own osabi setting/name, then I don't see why we couldn't start by > adding the osabi setting as soon as we have a use for it, even if > the larger Linux Kernel patches aren't ready yet. Following on from the above, for aarch64-linux-tdep we can apply domain knowledge regarding how things are configured. Here we know that TTBR0 is guaranteed to have top byte ignore set, TTBR1 does not *and* we also know (from memory-layout.txt) that TTBR0 is sufficiently small that bit 55 can be used to discriminate between the two cases. In others words regardless of whether we are running at EL0 or EL1 then I think we should mask the top byte from pointers if and only if bit 55 is unset, otherwise leave them as they are. Daniel.