Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)
On Mon, 2021-12-06 at 14:28 +0100, Pavel Labath wrote: > The live kernel debugging sounds... scary. Can you explain how would > this actually work? Like, what would be the supported operations? I > presume you won't be able to actually "stop" the kernel, but what will > you actually be able to do? > Yes, it is scary. No, the system doesn't stop -- it's just a racy way to read and write kernel memory. I don't think it's used often but I've been told that sometimes it can be very helpful in debugging annoying non-crash bugs, especially if they're hard to reproduce. -- Best regards, Michał Górny ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] RFC: How to handle non-address bits in the output of "memory read"
(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 (0x900f7ff8010) must be greater than the start address (0xa00f7ff8000). 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 = 0x3400f140 "\x80\xf1\xff\xff\xff\xff" (lldb) p ptr2 (char *) $5 = 0x5600f140 "\x80\xf1\xff\xff\xff\xff" (lldb) memory read ptr1 ptr2+16 0xf140: 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) 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. ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
