[Lldb-commits] [lldb] [lldb] Add 'FindInMemory()' overload for PostMortemProcess. (PR #102536)

[Miro Bucko via lldb-commits]

mbucko wrote:

> Thinking about this some more here are my thoughts: both `ObjectFile::PeekData` and `PostMoretemProcess::PeekMemory` should have a way to say "I am not implemented". Using either a llvm::Expected or std::optional. If `ObjectFile::PeekData` returns unimplemented, we need to fall back to `ObjectFile::CopyData`. If `PostMoretemProcess::PeekMemory` returns unimplemented, we need to fall back to standard `PostMoretemProcess::ReadMemory`. The main reason being: some core files are too large to mmap into memory and at some point we need to be able to not load the entire core file at once. If we don't load the entire core file, then we need to allow `PostMoretemProcess::PeekMemory` to succeed for areas it does have mapped into the process, and fail for areas where it can't. If we build in the fallback stuff as mentioned, then this all continues to work.
> 
> So the main idea is: if either ObjectFile or PostMortemProcess can return a reference to the data in the Peek calls, then should as long as they have this data mapped into the LLDB address space and can hand out a pointer to the data. If they can't, we should fall back to something that can copy the data into a buffer as mentioned with `CopyData` or `ReadMemory`. Core files or object files might compress up their data, in which case we wouldn't be able to hande out a buffer from calls to Peek, but we would need to unzip the buffer into the buffer supplied by CopyData and ReadMemory on the fly.

This is already the behavior, if ObjectFile::PeekData returns anything other than an array with expected size, we fall back to the default implementation which uses the original ReadMemory() method.

https://github.com/llvm/llvm-project/pull/102536