From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /YmfOd79tF//HwAAWB0awg (envelope-from ) for ; Wed, 18 Nov 2020 05:56:30 -0500 Received: by simark.ca (Postfix, from userid 112) id DFDF91F08B; Wed, 18 Nov 2020 05:56:30 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 001FB1E58F for ; Wed, 18 Nov 2020 05:56:29 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4E954385803C; Wed, 18 Nov 2020 10:56:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E954385803C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605696989; bh=8kQuhLWFLFVaL/Wm2/4dWYYu67U4xr5DgLdoMse2oy0=; 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=CEy5/fZ2ZR/RSo4wBpNICgPIug3kFFutEJiVtdCwzRPZypJ7com9vgVGQwxrMwU2s YMOzEF+uG/1pXOtC+dvfS7L5p8OXDaiiiE+zlU+z9EmDCtC9MV92QQVnLIT96LH4WG Z/n7EmKwLTWonnhh2TBzH4ZOFOdvFR7ad9ZsF6AY= Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by sourceware.org (Postfix) with ESMTPS id 0BEEB385800A for ; Wed, 18 Nov 2020 10:56:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0BEEB385800A Received: by mail-qv1-xf32.google.com with SMTP id a15so793636qvk.5 for ; Wed, 18 Nov 2020 02:56:25 -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=8kQuhLWFLFVaL/Wm2/4dWYYu67U4xr5DgLdoMse2oy0=; b=n7Kd+v0GxYxYq71RfLkND50ghxzh5tQy5EQb/hFyup9E8WuEgAVjwhM3oGUAD0pa2A KLvPuoBAYYmGboMlCdCrQzT6ngNVl/N/pWQbbvLIDalPvFsht0z391GjK6cGNVXDsiWy ZQ29u2abc1kZEtv5ET25ak6OD2cK4ArOiBP2Mbh381/Z7eDR+OW0x7nDrUjDHDlvjFyn zSJL1uFtX61b0Ikqkx7R8LKUwa/4A8aBcamf1XXmEm4qBxci6Zo4R2HVBXK9FwZTcxGy Dvb/AJpkgUIkVRk1AaViuBrVUmwZm0xiLEqizyPaxV30OydgBPIoUpNmw0KfXw7rVRf9 YAGw== X-Gm-Message-State: AOAM530iK0LgAI8M11vQcqs/wvSH/Rdcj6vE/seWbFBRPeJpbWcqkro1 3toFeynHuzR7Ieuw9fbfiip8aqxM63JttQ== X-Google-Smtp-Source: ABdhPJwukVrsA/PEcU6N0OUSzx2idbn4KCtUu+xMpbPdkFzVP+ENWVNgkShHirfeQ1E6HW3DFXY9zQ== X-Received: by 2002:a0c:b34a:: with SMTP id a10mr4142261qvf.15.1605696983972; Wed, 18 Nov 2020 02:56:23 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:370e:b4f7:71cf:fcce:a2f7? ([2804:7f0:8284:370e:b4f7:71cf:fcce:a2f7]) by smtp.gmail.com with ESMTPSA id 72sm16478799qkn.44.2020.11.18.02.56.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 02:56:23 -0800 (PST) Subject: Re: [PATCH v3 07/24] Documentation for memory tagging remote packets To: David Spickett References: <20201109170435.15766-1-luis.machado@linaro.org> <20201109170435.15766-8-luis.machado@linaro.org> <83ft5i4fwl.fsf@gnu.org> <08cb075e-018c-474e-abd4-b76ba1ed6a52@linaro.org> <27e9cc8e-95e6-4ac3-bd05-0f3846c96916@linaro.org> <7b5b77c2-1bc4-8810-93df-79343e67d1be@linaro.org> Message-ID: <84ff10d1-fc46-5632-7322-ba61a1c8a58f@linaro.org> Date: Wed, 18 Nov 2020 07:56:19 -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/18/20 7:39 AM, David Spickett wrote: >> I think the typo is still there. >> >> You meant 0,1,2 3 and 4, right? > > Sorry, long day. That is what I meant. > >> But I see what you mean. Even though the tag type name is "tag_logical" >> right now, the implementation choice is to interpret that as MTE for >> AArch64 and ADI for SPARC. Same thing for "tag_allocation". >> >> The rationale for having these two generic tag types ("tag_logical" and >> "tag_allocation") is that this technology may be common to multiple >> architectures (AArch64 and SPARC right now). >> >> Personally, I don't think having 4 type enums (mte_logical, >> mte_allocation, adi_logical and adi_allocation) would be better. That >> would require extra code for a similar technology. So, just to pass >> down, say, mte_logical instead of adi_logical, when those are in fact >> the same kind of tag/technology. >> >> Does that make sense? > > Yes it does. I'm not suggesting a combined type enum for all architectures. > >> The rationale for having these two generic tag types ("tag_logical" and >> "tag_allocation") is that this technology may be common to multiple >> architectures (AArch64 and SPARC right now). > > I think it's sketchy to think of logical and allocation as anything more than > "concepts". > > On a user interface level yes. logical tags come from pointers, that's the nice > way of summarising them. And you can have common code to show them in > common ways. > > Server side though the allocation tags for MTE and the allocation > tags for could/will have different interfaces > to read them. > (even if it is just a ptrace enum) > So the protocol needs to know the difference. (within the same architecture) > > See below... > >> For AArch64, these numbers would mean the following: >> >> 0 - MTE logical >> 1 - MTE allocation >> 2 - Capability >> >> For SPARC ADI, the following: >> >> 0 - ADI logical >> 1 - ADI allocation >> 2 - Unknown/Invalid > > My concern is what happens when comes in. Assume that: > * it also has tags referred to as logical and allocation > * it can be present alongside MTE in the same process/debug target > * the interface to read the allocation tags is different (aka it's a > different code path) > > If you say well, allocation tag is an > allocation tag like any other, > then the server gets "hey read me an allocation tag". But for what? > MTE or ? > > If you add these new tags as new enum values like: > 0 - MTE logical > 1 - MTE allocation > 2 - Capability > 3 - logical > 4 - allocation > > Then the server gets "hey read me a allocation tag". > This has been my plan so far. The fact we're adding generic logical/allocation tag types right now is to accommodate ADI, which uses similar technology. A new technology will have to use a different identifiers in the enum definition. I'm not planning on overloading tag types with more than one meaning per-architecture. That is, tag_logical will always be MTE logical for AArch64. > There's an argument to be made that this isn't a real problem and > might never happen, > and if it did you could add some kind of priming packet. "I'm going to > read MTE", "read me an allocation tag". > qMemTagsEX, whatever. > > I just think you could avoid that right now by encoding the type in > the way I suggested. I think we have the same model in mind, but somehow it has not been made clear. > (again, in the protocol, clients can map it however they want to reuse code) > > I'll try to summarise where I'm at: > > Grouping similar tag kinds (as in 0 = logical for SPARC ADI and 0 = > logical for MTE also) doesn't bother me. > We've got plenty of ints to go around and yes it does help the client > share some code. > > As long as, within the same architecture (aarch64 here), the server > can tell MTE from . Right. This is what I had in mind. > If we document the intent of the "type" field in the protocol I think > that fixes this, since the use case is academic at this point. > I suggest something like: > "This type value is per architecture and each value encodes the > architecture specific tagging technology used (e.g MTE) and the tag > kind (e.g. logical or allocation)." > > > If it makes sense to say "Architectures that want to add memory > tagging support may choose to overlap with existing values from other > architectures to reuse existing commands..." then great. > We've made the intent clear. > > This leaves the door open for SPARC ADI to do as you suggested and > overlap their logical/allocation with aarch64 mte and reuse the > existing code. > But it also confirms that will get new type > values regardless of whether it has things called logical/allocation > tags. > So that servers can tell them apart. > > This means your code in these patches doesn't need to change at all. > Right now we have the convenience of lining up the logical/allocation > kinds and if that > changes in future then the clients can change. (for example we add a > mapping from aarch64 tag types back to the smaller generic list of tag > types) > > Which is a lot of words to ask for a small docs addition, but > hopefully my hypothetical use case is clear? I think we've reached the important part here. Do you want clarification, through documentation, that we're going to stick with unique tag type identifiers per-architecture? I was slightly confused because unique identifiers per-architecture were my goal from the start, but somehow we got lost in discussing some of these tag type ambiguity cases. > > On Tue, 17 Nov 2020 at 17:29, Luis Machado wrote: >> >> On 11/17/20 12:16 PM, David Spickett wrote: >>>> Right now you can infer the technology and logical/allocation from the >>>> type. There is no need for a two step process. I don't anticipate a need >>>> for that in the future either, as long as we prevent the tag type ENUM >>>> from having overlapping values. >>> >>> Right, so to not overlap, a value of that tag type ENUM must be a >>> combination of technology and tag...kind. (words are hard) >>> E.g. MTE logical tag, allocation tag , strange tag >> >> Why? It only needs to be a unique value that represents a unique >> combination. See below. >> >>> >>> So if were to also have "logical" and >>> "allocation" tags, they would be new type values, yes? >>> 0 = MTE logical >>> 1 = MTE allocation >>> 2 = logical >>> 3 = allocation >>> >>> Because if they are still 0 and 1, they overlap and you can't tell MTE >>> and apart. >> >> I think there is some confusion here. Let me try to clarify. >> >> Yes, we currently only have tag types 0 and 1 (AArch64's MTE and SPARC >> ADI technologies, logical/allocation kind). If we add more tag >> technologies, we will also add new code/commands that will pass the >> appropriate tag types down to the target/remote layer. >> >> For example, if we end up supporting capability tags as a new type of >> tag (say, type 2, given we already have 0 and 1) , we will have to >> modify the code to handle that. It will be either a new command or new >> code to handle it. >> >> The target/remote layer will only see unique numbers 0, 1 and 2. >> >> For AArch64, these numbers would mean the following: >> >> 0 - MTE logical >> 1 - MTE allocation >> 2 - Capability >> >> For SPARC ADI, the following: >> >> 0 - ADI logical >> 1 - ADI allocation >> 2 - Unknown/Invalid >> >>> >>> I get that at the user interface layer you have some mapping back to a >>> set of generic types, talking just about the >>> packet contents. >>> >>>> So this is wrong, as the remote/native side won't be able to tell both >>>> definitions of type "1" apart. >>> >>> Sorry that was a typo. Should be: >>> 0 = mte logical, 1 = mte allocation, 1 = future logical, 2 = future >>> allocation, 3 = future tag form (not logical/allocation) etc... >>> (basically what I restated above) >> >> I think the typo is still there. >> >> You meant 0,1,2 3 and 4, right? >> >> But I see what you mean. Even though the tag type name is "tag_logical" >> right now, the implementation choice is to interpret that as MTE for >> AArch64 and ADI for SPARC. Same thing for "tag_allocation". >> >> The rationale for having these two generic tag types ("tag_logical" and >> "tag_allocation") is that this technology may be common to multiple >> architectures (AArch64 and SPARC right now). >> >> Personally, I don't think having 4 type enums (mte_logical, >> mte_allocation, adi_logical and adi_allocation) would be better. That >> would require extra code for a similar technology. So, just to pass >> down, say, mte_logical instead of adi_logical, when those are in fact >> the same kind of tag/technology. >> >> Does that make sense? >> >>> >>>> If we want to address this and make it a bit more flexible, then we will >>>> need to let architectures define their own tag type values. Then generic >>>> code will have to go through an arch-specific hook to fetch the tag type. >>> >>>> Would that address your concerns? >>> >>> I think so. I thought of this working like the breakpoint types I >>> referenced. Breakpoint type 1 for MIPS isn't in any way the same as >>> type 1 for Arm etc. >>> (ok they might be similar but the docs make it clear that the list of >>> types is per architecture) >>> >> >> I think the situation is similar here. I opted to group similar things >> together in the type names. >> >> mte_allocation is similar to adi_allocation, but they're different in >> that mte_allocation has granule size 16, while adi_allocation has >> granule size 64. >> >> mte_logical is exactly the same as adi_logical. They are both 4 bits in >> size. >> >>>> As long as GDB sends a unique tag type identifier (non-overlapping >>>> values), we will be able to tell them apart from the remote side. >>> >>> Yes but depending on how those IDs are allocated we may only be able >>> to tell logical vs allocation not MTE vs CHERI vs . >>> >>> On Tue, 17 Nov 2020 at 14:44, Luis Machado wrote: >>>> >>>> On 11/17/20 9:29 AM, David Spickett wrote: >>>>>> Right. The type is really telling you what specific kind of tag you are >>>>>> requesting, not the technology. So it may be perfectly valid to request >>>>>> a MTE logical tag from the remote target, but the remote target doesn't >>>>>> know how to reply to that at the moment (nor does it make much sense, IMO). >>>>>> >>>>>> The tag types don't overlap at the moment, given they are an ENUM in >>>>>> generic code. So the server will tell them apart by their values. >>>>> >>>>> Ok but my concern here is that there are two aspects to type. (which I >>>>> probably confused earlier tbf) >>>>> >>>>> 1. logical vs allocation >>>>> 2. MTE vs >>>>> >>>>> So we have three scenarios: >>>>> 1. Server uses type to decide between logical and allocation >>>> >>>> Right now 0 maps to logical and 1 maps to allocation for all >>>> architectures. For AArch64 0 maps to MTE logical and 1 maps to MTE >>>> allocation. >>>> >>>> But, if more tag types are supported in the future, we will need to map >>>> types to logical, allocation or something else. >>>> >>>>> 2. Server uses type to decide between MTE and >>>> >>>> Right now 0 and 1 map to MTE for AArch64 and ADI for SPARC (not yet >>>> supported). In the future, if there are more tagging technologies, we >>>> will need to provide a mapping from tag types to tag technology. >>>> >>>>> 3. The combination of the two, should a system have both technologies >>>> >>>> In this case, we will use two mappings: type to tag type and type to tag >>>> technology. >>>> >>>>> >>>>> What I want to avoid is a two step process: >>>>> 1. Somehow select tagging technology you want to interact with >>>>> 2. You send memtag packets with the logical vs allocation "type" >>>>> >>>>> Which would be needed if the protocol "type" is just allocation vs >>>>> logical. If the "type" includes the technology >>>>> then we can do it in one step. >>>> >>>> Right now you can infer the technology and logical/allocation from the >>>> type. There is no need for a two step process. I don't anticipate a need >>>> for that in the future either, as long as we prevent the tag type ENUM >>>> from having overlapping values. >>>> >>>>> >>>>> So I prefer: >>>>> 0 = mte logical, 1 = mte allocation, 1 = future logical, 2 = future >>>>> allocation, 3 = future tag form (not logical/allocation) etc... >>>> >>>> So this is wrong, as the remote/native side won't be able to tell both >>>> definitions of type "1" apart. >>>> >>>>> Over: >>>>> 0 = logical, 1 = allocation, 2 = future term for other tag form etc... >>>> >>>> This is correct in my view. Everything is unique. >>>> >>>> The complicating factor here is that generic code/UI needs to use a >>>> generic tag type so all architectures supporting memory tagging can use >>>> the commands out of the box. >>>> >>>> For AArch64, tag_logical/tag_allocation means MTE logical/MTE >>>> allocation. For SPARC ADI, this means whatever their tagging mechanism is. >>>> >>>> If we turn tag_logical into mte_logical, SPARC ADI won't be able to use >>>> that. We will, again, need a mapping. >>>> >>>> If we want to address this and make it a bit more flexible, then we will >>>> need to let architectures define their own tag type values. Then generic >>>> code will have to go through an arch-specific hook to fetch the tag type. >>>> >>>> Would that address your concerns? >>>> >>>>> >>>>> I see the need for the second form in gdb internally, but my concern >>>>> is only with the protocol side. >>>> >>>> As long as GDB sends a unique tag type identifier (non-overlapping >>>> values), we will be able to tell them apart from the remote side. >>>> >>>>> >>>>>> I just want to keep that option open >>>>>> if someone wants to do it, or if some other type of tag shows up that >>>>>> would require such support. >>>>> >>>>> I hadn't thought of that. I agree that type should include that too. >>>>> >>>>> On Tue, 17 Nov 2020 at 12:01, Luis Machado wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 11/17/20 7:05 AM, David Spickett wrote: >>>>>>>> Right now the design makes these types architecture-specific. >>>>>>> >>>>>>> This works too, in fact it matches the breakpoint types example better that way. >>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> Tell me if I have this right. >>>>>>> >>>>>>> In gdb in overall you have these two types but the server only uses >>>>>>> one of them, the allocation tag type. >>>>>>> So only the allocation tag type will ever go over the protocol. (for >>>>>>> MTE at least) >>>>>> >>>>>> That's correct. Only GDB knows about logical tags. Those don't make >>>>>> their way to the remote via the remote protocol. >>>>>> >>>>>>> >>>>>>> Given that, if we assume that "mte allocation" type is 1. A future >>>>>>> AArch64 kind of memory tagging could allocate 2 and on for its tag >>>>>>> types. >>>>>>> Something like: >>>>>>> AArch64 Memory Tag types - >>>>>>> 0 : MTE logical (which is internal only, reserved but documented as >>>>>>> unused, or left out completely?) >>>>>>> 1 : MTE allocation (the one we use at present) >>>>>>> 2: logical tag (because maybe there is some server >>>>>>> component for this kind of tagging extension?) >>>>>>> 3: allocation tag >>>>>>> >>>>>>> The reason I want to clarify is that I understood the type to >>>>>>> differentiate tagging technologies, not the kind of tag within them. >>>>>>> (the type tells you MTE vs instead of allocation vs logical) >>>>>>> The use case being what if you have MTE and active >>>>>>> in the same target and I want to set an MTE allocation tag, >>>>>>> how can the server tell them apart? >>>>>> >>>>>> Right. The type is really telling you what specific kind of tag you are >>>>>> requesting, not the technology. So it may be perfectly valid to request >>>>>> a MTE logical tag from the remote target, but the remote target doesn't >>>>>> know how to reply to that at the moment (nor does it make much sense, IMO). >>>>>> >>>>>> The tag types don't overlap at the moment, given they are an ENUM in >>>>>> generic code. So the server will tell them apart by their values. >>>>>> >>>>>>> >>>>>>> If the type numbers overlap between tagging technologies, we can't >>>>>>> tell them apart. >>>>>>> However if they encode what extension they are for and the >>>>>>> logical/allocation type (as in the example above) then we can. >>>>>>> >>>>>>> A lot of that is probably academic given there's one relevant type but >>>>>>> we can at least document the intent of the field. >>>>>>> E.g. "these types are global to AArch64 so new types should not >>>>>>> overlap existing ones" >>>>>> >>>>>> I suppose. I chose to have generic ENUM's without specific references to >>>>>> MTE for that reason. Architectures can use logical/allocation tags as >>>>>> they see fit, but the ENUM values will not overlap. >>>>>> >>>>>> We need to support the UI as well, so there needs to be some generic >>>>>> definitions so commands can query different tag types. >>>>>> >>>>>>> >>>>>>>> Otherwise we'd need to standardize on particular tag type names across >>>>>>>> different architectures, like "hw memory tag", "sw memory tag", >>>>>>>> "capability tag" etc. >>>>>>> >>>>>>> Well I was thinking of type more as a single value like "mte". Anyway >>>>>>> I'm fine with the integer route. >>>>>> >>>>>> Though we don't have a use for requesting logical tags from the remote >>>>>> targets, it is possible to support that. Passing "mte" or any other >>>>>> technology name would close that option. >>>>>> >>>>>> If, for example, we decide to have a dumb GDB client and a smart >>>>>> GDBserver (unlikely at this point), then it would make sense to pass >>>>>> down logical tag requests I think. I just want to keep that option open >>>>>> if someone wants to do it, or if some other type of tag shows up that >>>>>> would require such support. >>>>>> >>>>>>> >>>>>>> On Mon, 16 Nov 2020 at 17:23, Luis Machado wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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.