From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21859 invoked by alias); 20 Apr 2018 14:34:20 -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 21836 invoked by uid 89); 20 Apr 2018 14:34:19 -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,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=admit, H*c:alternative, office, metal X-HELO: mail-qt0-f169.google.com Received: from mail-qt0-f169.google.com (HELO mail-qt0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Apr 2018 14:34:15 +0000 Received: by mail-qt0-f169.google.com with SMTP id l8-v6so9714943qtp.6 for ; Fri, 20 Apr 2018 07:34:15 -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; bh=h7D9CjhljvMPL3SOXGLaBTVTChnzH+Z0qMCkSktmYUc=; b=NdKvO/tbVLA+WPJdmWhlSXb0d0iiAqMfcuLsgB1IZPP4GLQwmb3O5XrlkIdS8dP++2 8bGqw6/S9aaymQyoiwDQP2k4uLQm0GL+O3ckEpHDdBDfuF20kDhRl8o2Nkfw4Ruzlau+ 50M8I69YJaWsPfxKlucd3oN1Gd0NXDncg0DcyVWQZwpzkJe/Qll4xBZy52bKXAM/saRS PVpV+5wVhTV++44y4bMJTdoq0LKkV5qHUow1pR5l35PsRDOlg5iB6SGIMC+N/rVfYVhL sMrt7zFIjGRSHMYlJ+hR3NXRhrmrcnHV4rIXSutd8VB0kwDQFjRKIWR9hhgDQTjBb9BR INcg== X-Gm-Message-State: ALQs6tA/RUUy7lM8ucHu/ldHYr43WoymH6etQYUBDNpwGj0tJj8xBTpJ jVWpnCpSFlj8bqsj47HBnrE0V4t6Z1zYosebrNfO3A== X-Google-Smtp-Source: AIpwx4+0cb3KeSf9j0u+otj0YEZUDQwfCevR7av2nSKRFFFocAgRziBhxt9dD4fY6iBAD1EoDzomLXHuqt+uvJo/UjU= X-Received: by 2002:ac8:2fb4:: with SMTP id l49-v6mr11115485qta.195.1524234853550; Fri, 20 Apr 2018 07:34:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.67.82 with HTTP; Fri, 20 Apr 2018 07:33:43 -0700 (PDT) In-Reply-To: <56373ed6-3a63-4508-61fa-54a3a456d785@redhat.com> 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: Fri, 20 Apr 2018 14:34:00 -0000 Message-ID: Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Pedro Alves Cc: Yao Qi , GDB Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00402.txt.bz2 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_bit > >> 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 space > >> and clear or set top byte of the address even in case of linux targets. > >>> > >>> 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. 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. 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. > Thanks, > Pedro Alves >