From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129007 invoked by alias); 27 Apr 2018 16:29:03 -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 128994 invoked by uid 89); 27 Apr 2018 16:29:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Google-Smtp-Source:AB8JxZo, UD:memory-layout.txt, EL0, TTBRx X-HELO: mail-wr0-f196.google.com Received: from mail-wr0-f196.google.com (HELO mail-wr0-f196.google.com) (209.85.128.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Apr 2018 16:28:59 +0000 Received: by mail-wr0-f196.google.com with SMTP id 94-v6so1021611wrf.5 for ; Fri, 27 Apr 2018 09:28:58 -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=Nqmmn2nHRcfu56f/FTfjGcUXQu+y98QQJsDytpYbTc4=; b=UlGYOxmXGRFbfr2YoqYwT7KdwVU60rG6N484ygD8l95LDYEKqZ/nAnQ5ahoa4Qg7TY Y4/cUwMTL+HFDXN1IODPLwvQuj2XpzhUNhyDuQtkEPQY1nARRzW3lHRAxcx34bLp1YZo E+3SvmGQ0F9VXiIsEuXFJrM8b55CD862lAGWCF4fM59wQb7caRAwqBlXjx5jdhbND61l geatn3Kc7BoQby989JQ/6uuEGiRxZH5ravVuQnoxXIQCTeL9H0W7YLyAj5efljK90yJv rflagQYuRVzbMiRAhPcbjWC73Xxvwgs+xvAjtY4j3KUDTqlku0mWmHsXqqLaimA4gpMS gt8g== X-Gm-Message-State: ALQs6tB3vQNEUhM52gehiTJncnCf2IG2fVfg47emGSPUuHa24R/r5pr7 FebPYN+PU3uwd4BcShr0XgVhpw== X-Google-Smtp-Source: AB8JxZo/7pyWij4J7W07jQfqwsA8VI5565xwke6bg0b4Hj31DqCth9qIWIE4+bC8mfuyIMG094kPgw== X-Received: by 2002:adf:c908:: with SMTP id m8-v6mr2519339wrh.6.1524846537057; Fri, 27 Apr 2018 09:28:57 -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 n21sm1877127wmi.37.2018.04.27.09.28.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Apr 2018 09:28:56 -0700 (PDT) Date: Fri, 27 Apr 2018 16:29:00 -0000 From: Daniel Thompson To: Omair Javaid Cc: Pedro Alves , Yao Qi , GDB Patches Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer Message-ID: <20180427162854.hwjy3txygpzrunwt@holly.lan> References: <061e956c-72a7-2c2e-512b-3dfe42881818@redhat.com> <56373ed6-3a63-4508-61fa-54a3a456d785@redhat.com> <3f62b4ea-1f80-5faa-f372-b83b3e5de448@redhat.com> <20180424160538.kxvorrhvku4ukpj6@holly.lan> <20180425080432.kv4gagdcz7mhmx4x@holly.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180323 X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00570.txt.bz2 On Thu, Apr 26, 2018 at 01:11:04PM +0500, Omair Javaid wrote: > On 25 April 2018 at 13:04, Daniel Thompson wrote: > > On Wed, Apr 25, 2018 at 04:41:40AM +0500, Omair Javaid wrote: > >> >> 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. > >> > >> What I am understanding here is that you are basing your decision on > >> the fact that: > >> > >> "User addresses have bits 63:48 set to 0 while the kernel addresses have > >> the same bits set to 1. TTBRx selection is given by bit 63 of the > >> virtual address." > >> > >> Sounds legitimate for now but are we ever going to use more than > >> 48-bit virtual addresses in arm64 linux? > > > > Almost guaranteed I would have thought! > > > > However since the suggestion is *not* based on the assumption that bits > > 63:48 are zero then I don't think this matters. > > > > It is based on the assumption that bits 63:56 are unknown and cannot be > > used for decision making (because tag 0xff is not reserved) and also > > that bit 55 is not part of the VA. Bits 54:48 are not involved at all. > > > > For 52-bit VAs (and any other number of bits <56) the hueristic remains > > correct. > > > > For 56-bit VAs the pointer tagging feature cannot survive without being > > changed because with bit 55 allocated there would be no way for the > > hardware to discriminate between TTBR0 and TTBR1 pointers either. Thus > > whilst I don't deny the possibility that 56-bit addresses may eventually > > happen, *any* implementation of pointer tagging support in gdb would > > need to be updated at that point anyway. > > Above discussion seems to have sufficient points in favor of using bit > 55 as the indicator bit for pointer tagging on osabi Linux. When you say "use as indicator bit" is it not clear if you are still considering modal behaviour (pointer tagging is "on" or "off" based on bit 55 of one of the pointer registers) or whether you hope to move the masking function into the tdep code (so instead of saying all pointers at 56-bit, you can say all pointers need filtering in this manner). Conditional masking based on bit 55 is idempotent so there's no risk even if the filtering is applied multiple times at different places in gdb! > While we should also remove tagging support from non linux osabi. Agree. This is perhaps more urgent since then at least a non-Linux gdb can be used to debug the kernel. As things stand today no gdb-8.1 version can be used for AArch64 kernel debugging. Daniel.