[lldb-dev] RFC: How to handle non-address bits in the output of "memory read"

[Stephen Hines via lldb-dev]

Hi David,

Sending this message again as I'm now back from vacation (and I was finally
able to subscribe to lldb-dev - non-subscribers are prevented from sending
email to it).

On Fri, Dec 10, 2021 at 1:56 AM David Spickett <david.spickett at linaro.org>
wrote:

> (Peter and Stephen on CC since you've previously asked about this sort of
> thing)
>
> This relates to https://reviews.llvm.org/D103626 and other recent
> patches about non-address bits.
>
> On AArch64 we've got a few extensions that use "non address bits".
> These are bits beyond the (in most cases) 48 bit virtual address size.
> Currently we have pointer authentication (armv8.3), memory tagging
> (armv8.5) and top byte ignore (a feature of armv8.0-a).
>
> This means we need to know about these bits when doing some
> operations. One such time is when passing addresses to memory read.
> Consider two pointers to the same location where the first one has a
> greater memory tag (bits 56-60) than the second. This is what happens
> if we don't remove the non-address bits:
> (lldb) memory read mte_buf_alt_tag mte_buf+16
> error: end address (0x900fffff7ff8010) must be greater than the start
> address (0xa00fffff7ff8000).
>
> A pure number comparison is going to think that end < begin address.
> If we use the ABI plugin's FixDataAddress we can remove those bits and
> read normally.
>
> With one caveat. The output will not include those non address bits
> unless we make special effort to do so, here's an example:
> (lldb) p ptr1
> (char *) $4 = 0x3400fffffffff140 "\x80\xf1\xff\xff\xff\xff"
> (lldb) p ptr2
> (char *) $5 = 0x5600fffffffff140 "\x80\xf1\xff\xff\xff\xff"
> (lldb) memory read ptr1 ptr2+16
> 0xfffffffff140: 80 f1 ff ff ff ff 00 00 38 70 bc f7 ff ff 00 00
> ........8p......
>
> My current opinion is that in this case the output should not include
> the non address bits:
> * The actual memory being read is not at the virtual address the raw
> pointer value gives.
> * Many, if not all, non address bits cannot be incremented as the
> memory address we're showing is incremented. (not in a way that makes
> sense if you think about how the core interprets them)
>
>
I agree that the printed addresses should not include any of the ignored
top byte, because lldb is displaying what's at the actual virtual address
now, and not how we got there (i.e. the pointer).


> For example once you get into the next memory granule, the memory tag
> attached to it in hardware may be different. (and FWIW I have a series
> to show the actual memory tags https://reviews.llvm.org/D107140)
> You could perhaps argue that if the program itself used that pointer,
> it would use those non address bits as well so show the user *how* it
> would access the memory. However I don't think that justifies
> complicating the implementation and output.
>
> So what do people think of that direction? I've thought about this for
> too long before asking for feedback, so I'm definitely missing some of
> the wood for the trees.
>
> Input/bug reports/complaints from anyone who (unlike me) has debugged
> a large program that uses these non-address features is most welcome!
>
> Thanks,
> David Spickett.
>

We have a customer who is encountering issues with this in LLDB today, so I
asked them to comment on this thread (but I'm not sure if they will). The
current behavior prevents them from using LLDB with their core dumps.

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20220104/9afddbbf/attachment.html>