labath wrote: > That being said, if there is something we can do to this PR to make it easy > for you (Pavel) to implement this feature, we can make those changes. Like I > think it would be fair to change all `PeekMemory/DoPeekMemory` over a virtual > `ReadMemory/DoReadMemory` that returns a `DataExtractor` as this can easily > take place of the `ArrayRef<uint8_t>` values that are returned. > > This: > > ``` > virtual llvm::ArrayRef<uint8_t> PeekMemory(lldb::addr_t low, lldb::addr_t > high); > ``` > > Could become: > > ``` > virtual DataExtractor ReadMemory(lldb::addr_t low, lldb::addr_t high); > ``` > > And we can adjust all users of `PeekMemory` and `DoPeakMemory` to use the the > above functions?
I'm not sure which feature are you referring to now. I'm not particularly worried about the `/proc/kcore` use case, as I don't know if I'll ever get to that, and it will require more substantial changes anyway. The thing I am looking into right now is the ability to make `memory find` better in general, and not just for core files. My thinking is that if I can implement (and I'm offering to do that) a better generic implementation of `memory find` then probably the entirety of this patch becomes redundant. But to know that for sure, I'd like to understand more about your motivation for it. Like, what is the main problem that you're trying to solve with this? Is it to fix some specific bug (my bug was that the operation aborts as soon as it encounters a hole in the address space)? Or is it to make it faster? If so, what level of performance would you consider satisfactory? 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
