[Lldb-commits] [PATCH] D117299: [lldb] Ignore non-address bits in "memory find" arguments

[Muhammad Omair Javaid via Phabricator via lldb-commits]

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