summaryrefslogtreecommitdiff
path: root/lldb/test/API/functionalities/memory/holes
AgeCommit message (Collapse)Author
2024-09-04[lldb] Fix and speedup the `memory find` command (#104193)Pavel Labath
This patch fixes an issue where the `memory find` command would effectively stop searching after encountering a memory read error (which could happen due to unreadable memory), without giving any indication that it has done so (it would just print it could not find the pattern). To make matters worse, it would not terminate after encountering this error, but rather proceed to slowly increment the address pointer, which meant that searching a large region could take a very long time (and give the appearance that lldb is actually searching for the thing). The patch fixes this first problem by detecting read errors and skipping over (using GetMemoryRegionInfo) the unreadable parts of memory and resuming the search after them. It also reads the memory in bulk (`max(sizeof(pattern))`), which speeds up the search significantly (up to 6x for live processes, 18x for core files).
2024-09-03[lldb] Support partial memory reads on windows (#106981)Pavel Labath
ReadProcessMemory will not perform the read if part of the memory is unreadable (and even though the API has a `number_of_bytes_read` argument). To make this work, I explicitly inspect the memory region being read and only read the accessible part.
2024-09-02[lldb/linux] Make truncated reads work (#106532)Pavel Labath
Previously, we were returning an error if we couldn't read the whole region. This doesn't matter most of the time, because lldb caches memory reads, and in that process it aligns them to cache line boundaries. As (LLDB) cache lines are smaller than pages, the reads are unlikely to cross page boundaries. Nonetheless, this can cause a problem for large reads (which bypass the cache), where we're unable to read anything even if just a single byte of the memory is unreadable. This patch fixes the lldb-server to do that, and also changes the linux implementation, to reuse any partial results it got from the process_vm_readv call (to avoid having to re-read everything again using ptrace, only to find that it stopped at the same place). This matches debugserver behavior. It is also consistent with the gdb remote protocol documentation, but -- notably -- not with actual gdbserver behavior (which returns errors instead of partial results). We filed a [clarification bug](https://sourceware.org/bugzilla/show_bug.cgi?id=24751) several years ago. Though we did not really reach a conclusion there, I think this is the most logical behavior. The associated test does not currently pass on windows, because the windows memory read APIs don't support partial reads (I have a WIP patch to work around that).