Page MenuHomePhabricator

[lldb] Ignore non-address bits in "memory find" arguments

Authored by DavidSpickett on Jan 14 2022, 3:24 AM.



This removes the non-address bits before we try to use
the addresses.

Meaning that when results are shown, those results won't
show non-address bits either. This follows what "memory read"
has done. On the grounds that non-address bits are a property
of a pointer, not the memory pointed to.

I've added testing and merged the find and read tests into one

Note that there are no API side changes because "memory find"
does not have an equivalent API call.

Diff Detail

Event Timeline

DavidSpickett requested review of this revision.Jan 14 2022, 3:24 AM
DavidSpickett created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 14 2022, 3:24 AM
omjavaid added inline comments.Jan 20 2022, 4:11 PM

to to => to


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?

Fix "to to" in comment.

DavidSpickett marked an inline comment as done.Jan 21 2022, 2:31 AM
DavidSpickett added inline comments.

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.

omjavaid accepted this revision.Jan 23 2022, 8:46 PM
omjavaid added inline comments.

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.

This revision is now accepted and ready to land.Jan 23 2022, 8:46 PM