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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
