From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64592 invoked by alias); 24 Apr 2018 11:48:53 -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 50182 invoked by uid 89); 24 Apr 2018 11:48:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=benefits, mmu, intervention, hatch 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:48:27 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E0973F080F; Tue, 24 Apr 2018 11:48:20 +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 4821A202342E; Tue, 24 Apr 2018 11:48:20 +0000 (UTC) Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Omair Javaid 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: <3f62b4ea-1f80-5faa-f372-b83b3e5de448@redhat.com> Date: Tue, 24 Apr 2018 11:48: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/msg00459.txt.bz2 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. > 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. Thanks, Pedro Alves