omjavaid accepted this revision. omjavaid added inline comments. This revision is now accepted and ready to land.
================ Comment at: lldb/test/API/linux/aarch64/tagged_memory_access/TestAArch64LinuxTaggedMemoryAccess.py:83 + # Then that the location found does not display the tag bits. + self.assertNotRegexpMatches(out, "data found at location: 0x(34|56)[0-9A-Fa-f]+") ---------------- DavidSpickett wrote: > omjavaid wrote: > > so I am thinking do we actually need to omit tags from location address. > > Internally we want LLDB to ignore tags thats fine but user must be seeing > > the tagged address of buf so why omit tags in output of memory find? > > > TLDR: The logic here is that the tag (or more generally non-address) bits of > the pointer are a property of the pointer, not the memory pointed to. > > More detail, since I've thought about this a lot. Please challenge if it > doesn't make sense. > > You could argue that you're showing the user a "view" of memory through that > pointer. My problem there is that pointer auth and memory tagging break that > argument because you cannot assume they stay the same as the memory location > increments. Since you can't just assume that the signature for `ptr` and > `ptr+16` would be the same, or the memory tag for those locations would be > the same. > > The only minor benefit there is the user can copy a tagged pointer to a later > location, but those tags may not actually let the program access the memory. > (though the debugger can always but it didn't need tags to do that in any > case) > > This is what the full output looks like. If you wanted to display the tags in > the output which tag would you use? Well, simple choice is the start address > tag. However, it's really an arbitrary choice that I think doesn't help much. > > ``` > (lldb) p ptr1 > (char *) $2 = 0x3400000000411029 "" > (lldb) p ptr2 > (char *) $3 = 0x5600000000411029 "" > (lldb) memory find -s '?' ptr2 ptr1+16 > data found at location: 0x411038 > 0x00411038: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?............... > 0x00411048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > ``` > > I agree there is an initial "why did my pointer get changed" reaction but > think I not showing non-address bits when showing actual memory is going to > be clearer in the long run. Granted this is mostly intuition, we don't have a > lot of user feedback about this at this stage. > > Actual "memory tags" do have a tag that is attached to the memory location in > hardware, so you may want to show that. That's something I've been addressing > for "memory read" and will probably port that over to memory find as well. > It'll look something like: > > ``` > (lldb) memory find -s '?' ptr2 ptr1+16 > data found at location: 0x411038 > 0x00411038: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?............... > (tag: 0x1) > 0x00411048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > (tag: 0x2) > ``` > > Crucially here we're showing the real tag for each line, instead of assuming > that the one in the pointer can be applied to them all. This actually makes me think if we should try adding a feature where we can enable/disable viewing off non-address-bits. The purpose is to allow average programmer debug their simple applications without any surprise of ever changing memory addresses. May be with time people will realize the non-address bits technology but for programmers switching back n forth between x64 and AArch64 may feel things happening differently unless they figure there is this non-address bits phenomenon. Anyways your patch does make sense for now unless we hear any user complaints. Moreover additional tag information that you suggested above would be a good adon so +1 for that. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D117299/new/ https://reviews.llvm.org/D117299 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
