From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ag0KLxgEtV/GIAAAWB0awg (envelope-from ) for ; Wed, 18 Nov 2020 06:23:04 -0500 Received: by simark.ca (Postfix, from userid 112) id B21591F08B; Wed, 18 Nov 2020 06:23:04 -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 CCBDD1E58F for ; Wed, 18 Nov 2020 06:23:03 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 58E7C385480A; Wed, 18 Nov 2020 11:23:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 58E7C385480A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605698583; bh=J44Fb2Yaqn+N5UdyXHDk0rIjO3imhsNaGwDeVRCuMWc=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=VQd/6o9mR9RFKMBfD3jMHES0/tDE8Ap/ACpiaGlAzfUZhFQlgg0ygsX2EFKzugp6n Xp92QGes0c2HoWHL0tnmEPbp8E9d9tkV9sXGgoFTRiGz2b8ViSW5B/Fsq7NsAiwEir nTQ7ZW100nypp+fJLwCIdIBciTnbgTD/fuFqJv7U= Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) by sourceware.org (Postfix) with ESMTPS id 6A564385780A for ; Wed, 18 Nov 2020 11:22:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6A564385780A Received: by mail-vk1-xa2c.google.com with SMTP id m6so374990vkl.2 for ; Wed, 18 Nov 2020 03:22:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J44Fb2Yaqn+N5UdyXHDk0rIjO3imhsNaGwDeVRCuMWc=; b=h+gdB8asK6CB+rGlgA8R31+3IEXJ06l8SXRe6n/DWwTX82/l7jL3IzKC0wvyeaGVaL k2c2VtrPyMYrQvGIoKjIvJLgd969DNGlyL6SpNRuq1Sj43GZuIr/+o4Hx4kNZv2FGYMp N9Uf0zxurnm0J9zKSSvs5PRq61kqlCCQY8PRyEFPzU6I2VKqqx/Zu1k/pBQHmKeF+9BA skusEnco5Hpj3tBhqAwUjlQJfa18UbjYpG4BV+5/kJgI8S0gkrpP+jZ7/4q/MCStt8v0 PLSPIKmDo6ayKq2ttcc37RnVF+jnuexAg6rMbw+ZJnE5IshWyXQIgT74I1I09OI/DAiG sd/A== X-Gm-Message-State: AOAM531t3tx3yS0opazAjU+yeFAdSNajz/2xJNkR/YUQ+0QoXYjvMPRv RcZngnf/gq1fDrMG9IC0W9WDcR+rCMSOyhCKMCGgyQ== X-Google-Smtp-Source: ABdhPJxypmgoXH01qeHESvlXpbgEE7PH8xi6Z9/ifaXaqR8JLBnkfBFfx0Jk8gLeW2j63egDdVdsUEAyPqbSwGez1Zg= X-Received: by 2002:a05:6122:84f:: with SMTP id 15mr2626698vkk.25.1605698578667; Wed, 18 Nov 2020 03:22:58 -0800 (PST) MIME-Version: 1.0 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> <84ff10d1-fc46-5632-7322-ba61a1c8a58f@linaro.org> In-Reply-To: <84ff10d1-fc46-5632-7322-ba61a1c8a58f@linaro.org> Date: Wed, 18 Nov 2020 11:22:47 +0000 Message-ID: Subject: Re: [PATCH v3 07/24] Documentation for memory tagging remote packets To: Luis Machado Content-Type: text/plain; charset="UTF-8" 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: David Spickett via Gdb-patches Reply-To: David Spickett Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > That is, tag_logical will always be MTE logical for AArch64. Awesome, we're on the same page. > I think we have the same model in mind, but somehow it has not been made > clear. In future I will start by suggesting a concrete change before going into the reasoning. I think not doing so confused things. > 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? Yes, exactly. On Wed, 18 Nov 2020 at 10:56, Luis Machado wrote: > > 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.