jrtc27 added a comment. In D105182#2930795 <https://reviews.llvm.org/D105182#2930795>, @DavidSpickett wrote:
>> Many different types of memory tagging exist, MTE is but one. > > Sure. I'm not opposed to making changes to adapt to the properties of > different tags. However the most concrete one I have access to it MTE so that > has shaped the initial support and assumptions. > >> CHERI uses memory tagging for something completely different (tracking valid >> capability, ie pointer provenance), and its tags make sense to read (though >> are a property of the stored data, not the memory allocation), but not >> explicitly write (only implicitly by writing a capability to the associated >> location, which will include the non-addressable tag bit), as that is >> architecturally forbidden in order to ensure that the hardware-enforced tags >> can never be corrupted by software. > > Definitely we could add properties to the tagging scheme information to > disable the read and/or/write commands. Something like: > > (lldb) memory tag write 0x12341234 23 > Error: Cannot write memory tags for address 0x12341234. <foo> tags are not > writeable by user software > > If you mean hiding the commands completely from the interactive sessions, > there's no existing mechanism for it but you could make the argument for it. > The current pattern is to show the command but error saying that it is > unsupported. (this also happens when a remote doesn't support some feature) Yeah that kind of UI thing isn't really my concern. >> Moreover, in future, CHERI and MTE will be composed (there is ongoing >> experimental work to investigate doing so on CHERI-RISC-V, and if Arm's >> experimental Morello prototype is adopted in a future version of the Arm >> architecture it will also have to compose with MTE). See also the core dump >> format for MTE tags, which specifies the _type_ of tag, specifically to >> accommodate other uses of tagged memory. > > Certainly. There's nothing stopping us supporting such a configuration apart > from (at least personally) zero experience or way to test such a thing. > Something like: > > (lldb) memory read foo > Error: Current process has multiple memory tag types. "foo", "bar". Please > select one with the --type argument. > > It's not something I could really implement with just MTE as the vast > majority of the code would be untested but with a use case we could > definitely make the changes. My concern with that would just be that, if MTE is all that most users have accesses to for a while, various things will be written assuming `memory tag` means MTE and that if they run it on an MTE-less CHERI system it will do surprising things and they'll get confused. But maybe that doesn't matter and the benefit of having a shorter command when you only have one tag type outweighs that (though, LLDB is no stranger to verbose commands!). > Where this does become more thorny is the lldb API where we have more > stringent commitments to not changing it. Happily, I haven't started on this > yet and your concerns very much need to be included. Yes, I do think it's important that the API always be explicit in what type of tag is used, presumably with an initially single-member enum. > Perhaps you could write up something and post it to the lldb-dev list for > more visibility? I'd be interested to know how things work in the existing > lldb cheri port (I assume there is one, there is for Morello at least). I'll see if I can manage that over the weekend. FWIW, there is no CHERI LLDB, only a Morello LLDB, as our resident debugger expert is familiar with, and contributes to, GDB (and that's what we're also more familiar with using), though we have talked about wanting one. We don't currently have support for reading tagged memory in CHERI GDB, and I don't think Arm's Morello LLDB does currently either, they're both fairly limited in their functionality as we have other more pressing things to be working on. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105182/new/ https://reviews.llvm.org/D105182 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
