Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB
Hi all, the first series of changes for MTE has been in review phabricator for a while now. They have all bar one been approved by Omair Javaid and we'd like to start landing them with a view towards having MTE support for llvm 13. (there is another series waiting in the wings for tag writing) Not calling out anyone in particular who I might have added to any of the reviews, we're all busy folk. I'm just aware that memory tagging is an AArch64 Linux only feature right now and Omair and myself are both Linaro so I want to give others a chance to comment on the changes from a general lldb perspective. You can the changes here: https://reviews.llvm.org/D97281 https://reviews.llvm.org/D97282 https://reviews.llvm.org/D95601 https://reviews.llvm.org/D95602 https://reviews.llvm.org/D97285 Even if you are not familiar with memory tagging, if something generally sticks out, let me know. If I don't receive any request for changes in the next few days I'll start landing them. If you want to peek at the changes that aren't in review yet you can do so here: https://github.com/DavidSpickett/llvm-project/commits/mte_commands On Tue, 18 Aug 2020 at 11:09, David Spickett wrote: > > > The initial idea of commands like "memory showptrtag", "memory showtag", > > "memory checktag" - it might be better to put all of these under "memory > > tag ...", similar to how "breakpoint command ..." works. > > Sounds good to me, I didn't know there was a 3 level command in there > already. The names get a bit redundant since "memory tag set" doesn't > tell you which one of the pair it's setting. So we could have "memory > tag setptrtag" "memory tag setmemorytag", or make "set" one command > with variable arguments: > Set logical tag: memory tag set > Set logical and allocation: memory tag set > > Set only allocation: memory tag set --only-memory > (which I think is a bit neater) > > Where "pointer tag" and "memory tag" were the best generic names for > "logical" and "allocation" I came up with. (think of it like the > memory tag is attached to the memory, pointer tag is attached to a > pointer) > Also "memory tag check" can be removed since it's just "memory tag > show" with a warning on mismatch. > > > My general design is that the Process object will keep track of the # of > > bits used for virtual addresses. > > I hadn't considered this issue thanks for bringing it up. Your scheme > seems reasonable to me. I see that "addressing_bits" is in the > upstream qHostInfo but only in the RNBRemote, does that mean that > upstream already uses this in some way? (presumably just for Apple > platforms?) > > > I am working on a kernel patch which will make this information available > > via siginfo, and once the tag becomes available from the kernel you > > shouldn't need to decode the instruction. > > Great! I'll keep an eye on it. > > On Fri, 14 Aug 2020 at 02:40, Peter Collingbourne wrote: > > > > > > > > On Mon, Aug 10, 2020 at 3:41 AM David Spickett via lldb-dev > > wrote: > >> > >> Hi all, > >> > >> What follows is my proposal for supporting AArch64's memory tagging > >> extension in LLDB. I think the link in the first paragraph is a good > >> introduction if you haven't come across memory tagging before. > >> > >> I've also put the document in a Google Doc if that's easier for you to > >> read: > >> https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing > >> (please keep comments to this list though) > >> > >> Any and all comments welcome. Particularly I would like opinions on > >> the naming of the commands, as this extension is AArch64 specific but > >> the concept of memory tagging itself is not. > >> (I've added some people on Cc who might have particular interest) > >> > >> Thanks, > >> David Spickett. > >> > >> > >> > >> # RFC: AArch64 Linux Memory Tagging Support for LLDB > >> > >> ## What is memory tagging? > >> > >> Memory tagging is an extension added in the Armv8.5-a architecture for > >> AArch64. > >> It allows tagging pointers and storing those tags so that hardware can > >> validate > >> that a pointer matches the memory address it is trying to access. These > >> paired > >> tags are stored in the upper bits of the pointer (the “logical” tag) and in > >> special memory in hardware (the “allocation” tag). Each tag is 4 bits in > >> size. > >> > >> https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety > >> > >> ## Definitions > >> > >> * memtag - This is the clang name for the extension as in > >> “-march=armv8.5-a+memtag” > >> * mte - An alternative name for mmtag, also the llvm backend name for > >> the extension. > >> This document may use memtag/memory tagging/MTE at times, they mean > >> the same thing. > >> * logical tag - The tag stored inside a pointer variable (accessible > >> via normal shift and mask) > >> * allocation tag - The tag stored in tag memory (which the hardware > >> provides) >
Re: [lldb-dev] [cfe-dev] [llvm-dev] Mailing List Status Update
On Mon, Jun 21, 2021 at 12:53 PM Chris Lattner via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Jun 9, 2021, at 10:50 AM, Philip Reames via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Specific to the dev lists, I'm very hesitant about moving from mailing > lists to discourse. Why? > > Well, the first and most basic is I'm worried about having core > infrastructure out of our own control. For all their problems, mailing > lists are widely supported, there are many vendors/contractors available. > For discourse, as far as I can tell, there's one vendor. It's very much a > take it or leave it situation. The ability to preserve discussion archives > through a transition away from discourse someday concerns me. I regularly > and routinely need to dig back through llvm-dev threads which are years > old. I've also recently had some severely negative customer experiences > with other tools (most recently discord), and the thought of having my > employability and ability to contribute to open source tied to my ability > to get a response from customer service teams at some third party vendor I > have no leverage with, bluntly, scares me. > > Second, I feel that we've overstated the difficulty of maintaining mailing > lists. I have to acknowledge that I have little first hand experience > administering mailman, so maybe I'm way off here. > > Hi Philip, > > First, despite the similar names, Discord is very different than > Discourse. Here I’m only commenting about Discourse, I have no opinion > about Discord. > > > In this case, I think we need to highly weight the opinions of the people > actively mainlining the existing systems. It has become clear that the > priority isn’t “control our own lists”, it is “make sure they stay up” and > “get LLVM people out of maintaining them”. > > The ongoing load of maintaining these lists (including moderation) and of > dealing with the security issues that keep coming up are carried by several > individuals, not by the entire community. I’m concerned about those > individuals, but I’m also more broadly concerned about *any* individuals > being solely responsible for LLVM infra. Effectively every case we’ve had > where an individual has driving LLVM infra turns out to be a problem. LLVM > as a project isn’t good at running web scale infra, but we highly depend on > it. > > It seems clear to me that we should outsource this to a proven vendor. > Your concerns about discourse seem very similar to the discussion about > moving to Github (being a single vendor who was once much smaller than > Microsoft). I think your concerns are best addressed by having the IWG > propose an answer to “what is our plan if Discourse-the-company goes > sideways?" > Might also be worth some details on: "Why is Discourse more suitable than a hosted mailman solution?" - if the main goal is to get LLVM individual contributors out of maintaining infrastructure, moving to a hosted version of the current solution seems lower friction/feature creep/etc? (though I realize moving between solutions is expensive, and it may be worthwhile gaining other benefits that Discourse may provide while we address the original/motivating issue of maintenance) ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] Mailing List Status Update
On Mon, Jun 21, 2021 at 3:16 PM Kevin P. Neal via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Mon, Jun 21, 2021 at 12:58:22PM -0700, David Blaikie via cfe-dev wrote: > >>On Mon, Jun 21, 2021 at 12:53 PM Chris Lattner via cfe-dev > >><[1]cfe-...@lists.llvm.org> wrote: > >> > >>Hi Philip, > >>First, despite the similar names, Discord is very different than > >>Discourse. Here Iâm only commenting about Discourse, I have no > >>opinion about Discord. > >>In this case, I think we need to highly weight the opinions of the > >>people actively mainlining the existing systems. It has become > clear > >>that the priority isnât âcontrol our own listsâ, it is âmake sure > they > >>stay upâ and âget LLVM people out of maintaining themâ. > >>The ongoing load of maintaining these lists (including moderation) > and > >>of dealing with the security issues that keep coming up are carried > by > >>several individuals, not by the entire community. Iâm concerned > about > >>those individuals, but Iâm also more broadly concerned about *any* > >>individuals being solely responsible for LLVM infra. Effectively > >>every case weâve had where an individual has driving LLVM infra turns > >>out to be a problem. LLVM as a project isnât good at running web > >>scale infra, but we highly depend on it. > >>It seems clear to me that we should outsource this to a proven > >>vendor. Your concerns about discourse seem very similar to the > >>discussion about moving to Github (being a single vendor who was once > >>much smaller than Microsoft). I think your concerns are best > >>addressed by having the IWG propose an answer to âwhat is our plan if > >>Discourse-the-company goes sideways?" > > >Might also be worth some details on: "Why is Discourse more suitable > >than a hosted mailman solution?" - if the main goal is to get LLVM > >individual contributors out of maintaining infrastructure, moving to a > >hosted version of the current solution seems lower friction/feature > >creep/etc? (though I realize moving between solutions is expensive, > and > >it may be worthwhile gaining other benefits that Discourse may provide > >while we address the original/motivating issue of maintenance) > > I notice that Discord gets maybe 50-100 messages a day, IRC perhaps a > little less, but Discourse gets almost none. It's a very low daily number. > The mailing lists that I'm on (just clang and llvm) get 500+ messages a > day. > > Are we really going to replace email with Discourse when we can see that > almost nobody likes using Discourse? > > > Metcalfe's law - people are going to tend to use the medium that they are able to reach the audience on, but not necessarily because it's superior. Mailing lists have the benefit of long-term incumbency. I think I would prefer maintaining the status quo but if I woke up tomorrow and the conversation had moved to Discourse I would join it there. Regardless of whether it had moved by mandate or popular adoption. I suspect others may feel similar and therefore the traffic is not a good metric of preference. -- -Brian ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
