From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id IasjMnm1sl8kZgAAWB0awg (envelope-from ) for ; Mon, 16 Nov 2020 12:23:05 -0500 Received: by simark.ca (Postfix, from userid 112) id C09951F08B; Mon, 16 Nov 2020 12:23:05 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D3B411E552 for ; Mon, 16 Nov 2020 12:23:04 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 607CB384640E; Mon, 16 Nov 2020 17:23:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 607CB384640E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605547384; bh=5dsJQW+Gjs6JHKZ9HxvQTaFBl46d3fAu676xVS59nDk=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=E7JeqllBAvFBnMLJyB+UaRFZIo5TI1PoI7E2CJoDEkw4VMxPrDyzcvl/ONJf+HM5t S4UEu+bOeNwis3g+VBawVf4Exct5+BXFtHCXdjYTZXIkXwc4FjrJ+pPpDf46obrfju +8+9IB7hnjPS70E9vmmi/wOIcpzsWq3hru/InJnA= Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) by sourceware.org (Postfix) with ESMTPS id 635C7384640E for ; Mon, 16 Nov 2020 17:23:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 635C7384640E Received: by mail-qv1-xf44.google.com with SMTP id r12so9100672qvq.13 for ; Mon, 16 Nov 2020 09:23:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5dsJQW+Gjs6JHKZ9HxvQTaFBl46d3fAu676xVS59nDk=; b=fufYWQvx0EDTgW7cDa5D3+rFVvwpP6pV92rtTtr0H2k8yecw0n+E/rP0JU7ZDQeMjF 4TBakKwaR3Alfyb5OdaVPcmTIj/jtYlZXWM48oY0dIz/36ERdqfaptlfM+oONfn2bS9O L1X36rcJGZnvXGHS7TZdAgPKB9UT4eMOuDElip5vULuH3cuMrfOYBJU+VEuTqqYK0xad o/DwSY9tVL8pNeXsuE+lSnJ2yFOnHSAvD46O3ZXJH2CditMyfWvhmyhsSwiq+3WqP5gE SDRe9SyWHDA8WiqIh9OWDEX2G176PwthHglGYK75dD1AP1Wm7UE+eH12iwV6MkK6sQLr IW2A== X-Gm-Message-State: AOAM533XnrT0TNUD75aqtSkp7Sx5hcZYF6lntQdo6bNsv2GvhNScVHzp h/b7sIoc4mdpSZuxfpPRhVOMeu5M7FxpBg== X-Google-Smtp-Source: ABdhPJzH7Th+7t5jo5djKPFnYHpGM0JRl/F1A80THB/TApqxR4gRDqQN5f65PmHysouZ/WiDRwwnRQ== X-Received: by 2002:ad4:56ee:: with SMTP id cr14mr16880794qvb.15.1605547380069; Mon, 16 Nov 2020 09:23:00 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:1487:34cb:6ef2:6b7f:4db2? ([2804:7f0:8284:1487:34cb:6ef2:6b7f:4db2]) by smtp.gmail.com with ESMTPSA id a85sm12686791qkg.3.2020.11.16.09.22.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Nov 2020 09:22:59 -0800 (PST) Subject: Re: [PATCH v3 07/24] Documentation for memory tagging remote packets To: David Spickett , Eli Zaretskii References: <20201109170435.15766-1-luis.machado@linaro.org> <20201109170435.15766-8-luis.machado@linaro.org> <83ft5i4fwl.fsf@gnu.org> Message-ID: <08cb075e-018c-474e-abd4-b76ba1ed6a52@linaro.org> Date: Mon, 16 Nov 2020 14:22:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 11/16/20 1:04 PM, David Spickett wrote: > Also with regard to the "type" field. > >> +@var{type} is the type of tag the request wants to fetch. The typeis a signed >> +integer. > > (typo aside) Is this field architecture specific and will there be a > list of these type numbers documented anywhere? (or already is) > For example would 1 on AArch64 be MTE, and on be tag type>. Or would that be 2. > > My assumption has been that it is the latter and that a value means a > kind of tagging extension. So for example 1=MTE rather than > 1= mte logical and 2 = mte allocation. Correct me if I am wrong there. Right now the design makes these types architecture-specific. It would be nice to have more documentation about them, for sure. But there's one catch right now. The user-visible commands know about two types of tags (logical and allocation). The native/remote side of GDB only sees one type, the allocation one, as it doesn't make sense to ask the native/remote target about logical tags. This is slightly messy and, in my opinion, should be an implementation detail. So, in summary... We have a couple generic tag types GDB knows about: logical and allocation. Those types get translated to an arch/a target-specific type when they cross the native/remote target boundary. In theory we could have generic tag types 1 and 2 in generic code, but tag type 2 gets translated to type 1 in a remote packet. Maybe we could improve this a little. > > A page like: > https://sourceware.org/gdb/current/onlinedocs/gdb/ARM-Breakpoint-Kinds.html#ARM-Breakpoint-Kinds > > Or just a short note, given that there's only one type right now. Yes, that would be nice to expand for the tag types. > > Also, I may have suggested the type be a string at some point. However > based on examples like the link above > I don't see much advantage to it apart from making packet dumps easier > to read. Just wanted to close the loop on that > if I didn't before. I don't have a strong preference here. I'm just forwarding the tag type from generic code. If we want to pass strings, we will need a gdbarch hook that maps a type to a string in the remote target layer. Otherwise we'd need to standardize on particular tag type names across different architectures, like "hw memory tag", "sw memory tag", "capability tag" etc. > > > > On Mon, 16 Nov 2020 at 15:44, David Spickett wrote: >> >> Minor thing, there is a missing space here in "typeis". >> >>> +@var{type} is the type of tag the request wants to fetch. The typeis a signed >>> +integer. >> >> On Mon, 9 Nov 2020 at 17:08, Eli Zaretskii wrote: >>> >>>> Date: Mon, 9 Nov 2020 14:04:18 -0300 >>>> From: Luis Machado via Gdb-patches >>>> Cc: david.spickett@linaro.org >>>> >>>> gdb/doc/ChangeLog: >>>> >>>> YYYY-MM-DD Luis Machado >>>> >>>> * gdb.texinfo (General Query Packets): Document qMemTags and >>>> QMemTags. Document the "memory-tagging" feature. >>>> --- >>>> gdb/doc/gdb.texinfo | 96 +++++++++++++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 96 insertions(+) >>> >>> OK for this part, thanks.