From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81755 invoked by alias); 30 Apr 2018 13:42:08 -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 81447 invoked by uid 89); 30 Apr 2018 13:42:08 -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=gdb-8.1, survive, gdb81, considering X-HELO: mail-qt0-f194.google.com Received: from mail-qt0-f194.google.com (HELO mail-qt0-f194.google.com) (209.85.216.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Apr 2018 13:42:06 +0000 Received: by mail-qt0-f194.google.com with SMTP id m5-v6so10909012qti.1 for ; Mon, 30 Apr 2018 06:42:06 -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=n/hwzA1QsEk2BLxWJ1DcCJeuLrchIUvCa33wWnDjP58=; b=YrtpNSOuBIwgdHeivGReSFmyB0FZGJM/1GxdUEq5uhsWIKX+RXnb5x4tlmmGwzIQ7t t7R1svQMQJmF/Y97tILGxr0dK+0xTzcoSZYifdbF7XHi/b3muf2vEwP7IHVYuz/KbKLy BIZI9SRsFlsvx/FmtQXPtL7RXWMO3ltF5Mpy1bBqu2ci0U372JdTdWDGuX+XTSK9xOaa pSPuEbGnR1Ez/GzfPn7rXQ9SfqTbMXeC0fw1A6vdKhGeb/qlttiQG+K+cymHVahDuKMc DiTd4zlfFyPoia/NlSCOwXiZusoSfntT0LB3hHP+myw7JkDtWu2KC3W9xpYy1kTbd1K7 tVKA== X-Gm-Message-State: ALQs6tACU52WpwLDwhzlqhehZCNgWzJzWf7O+BOFFAMVS5HcvuaxO6dG njdSo9h0latHFPjDNdDARPwfUetRS07JstJxghwAFg== X-Google-Smtp-Source: AB8JxZq+J4O0n9FBc2mgPdi/oaWN2JJL3047AWL0IELPEHgjQJSwypWaKSWXxb61ivfnEUxX+k5GxYNAE56QPNLeOtM= X-Received: by 2002:ac8:3f23:: with SMTP id c32-v6mr11497590qtk.286.1525095724886; Mon, 30 Apr 2018 06:42:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.112.194 with HTTP; Mon, 30 Apr 2018 06:41:34 -0700 (PDT) In-Reply-To: <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> <20180427162854.hwjy3txygpzrunwt@holly.lan> From: Omair Javaid Date: Mon, 30 Apr 2018 13:42:00 -0000 Message-ID: Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Daniel Thompson Cc: Pedro Alves , Yao Qi , GDB Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00623.txt.bz2 On 27 April 2018 at 21:28, Daniel Thompson wrote: > 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. I have written a patch for this issue will be posting it on for review after testing. Approach i am using is to sign extend address based on 55th bit after clearing top byte. Clearing pointer tagging from aarch64-elf and only enabling it for aarch64-linux. > > > Daniel.