https://github.com/DavidSpickett commented:
Though it's not explicitly mentioned, I think the testing does cover the over/under alignment to fit to granules. That's what I spent the most time on for Linux. No testing on a packet level though. For lldb-server those live in lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py. Mostly it covers the invalid packet forms. No tests for truncated reads or skipping untagged regions. I suspect you can't have untagged memory as your MTE seems to be per process. So that would mean you can't fail to read tags either? Even if untagged regions are possible, I'd be ok with you leaning on the Linux tests to cover it since it requires making dodgy assumptions about `mmap`'s behaviour. I do think that truncated reads are worth testing if they are in fact possible. For Linux we just fail in this case, under the assumption that the memory tag manager should have looked for the gaps before it issued the reads. And any question of code quality in the debugserver parts is up to your Apple colleagues of course. https://github.com/llvm/llvm-project/pull/160952 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
