DavidSpickett wrote: > Isn't truncation here expected behavior? The underlying memory isn't there.
Seems like truncation is the most accurate representation of the situation when the unreadable memory is the last part of the range. But to handle gaps in any position, you'd have to invent new regions which is I think more misleading. So I can see why you'd go for zero padding. > @DavidSpickett is there anything here I'm missing where there could be an > unreadable hole in a VMA? I don't know much about memory management options. I can confirm that LLDB gets all its information from `/proc/<pid>/` `smaps` or `maps`. If the kernel tells us there is a region, we trust it. > When it saved a memory range that had an unreadable page in it, it: I wondered what ELF cores do for the same test case and they also zero pad. In the live process: ``` (lldb) memory region -a <...> [0x0000fffff7ff3000-0x0000fffff7ff7000) rw- /memfd:lldb_hole (deleted) (lldb) memory read 0x0000fffff7ff3000 0xfffff7ff3000: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ................ 0xfffff7ff3010: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ................ (lldb) memory read 0x0000fffff7ff3000+4096 error: memory read failed for 0xfffff7ff4000 ``` We fail to read beyond the first page, as expected. Then in a core: ``` $ /tmp/test.o region = 0xf28d0fbf9000, page = 4096 Trace/breakpoint trap (core dumped) $ readelf -l -W core.24900.106446.1785749733 Elf file type is CORE (Core file) Entry point 0x0 There are 18 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align <...> LOAD 0x03a000 0x0000f28d0fbf9000 0x0000000000000000 0x004000 0x004000 RW 0x1000 <...> ``` The region is all 4 pages. ``` (lldb) memory region -a <...> [0x0000f28d0fbf9000-0x0000f28d0fbfd000) rw- <...> (lldb) memory read 0x0000f28d0fbf9000 0xf28d0fbf9000: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ................ 0xf28d0fbf9010: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ................ (lldb) memory read 0x0000f28d0fbf9000+4096 0xf28d0fbfa000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xf28d0fbfa010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ``` And the core has zero padded the unreadable parts. So filling with zeros at least has precedent, but - > especially as this is the behavior I'm explicitly trying to remove in the > Linux kernel 😆! Maybe this is the behaviour you are trying to remove? https://github.com/llvm/llvm-project/pull/212641 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
