mbucko wrote: > It just so happens that I got a `memory find` bug today, which made me > realize just how broken the current behavior is -- it will effectively abort > the search as soon as it runs into any unreadable block of memory (plus it > also reads one byte at a time, which makes it excruciatingly slow for large > ranges). > > Now, this patch fixes both of those problems for core files (which implement > the required APIs), but it still leaves the operation for live processes in > its current, broken, state. This got me thinking whether it would be possible > to implement something like this PR in a way that benefits all > implementations -- and I think the answer to that question is "yes". > > The part where you skip over the holes in memory is implementable using the > existing GetMemoryRegion API which all processes implement (or should > implement). > > And we can certainly do something to avoid copying in the ReadMemory calls. > Probably the best think to do would be to have a `ReadMemory` overload which > returns a DataExtractor. This will give individual implementations the choice > of how to return the memory. Implementations (like the core files, but maybe > not all of them) which have the memory available already, can just return a > DataExtractor referencing existing memory, while others (most live processes) > can create a new DataBuffer object to back the DataExtractor. > > I think that would give us most of the performance of the current > implementation for core files, and also significantly improve the live > process situation. (And we'd also have a single implementation). > > What to you (all) think? Note that this isn't something I expect you must do > on your own. Since this is something that I now need to do on my own anyway, > I'd be happy to do some or all of this work myself.
This would be quite the rework of the FindInMemory() API. Would it be worth creating an Issue and move the discussion there to unblock this PR? 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
