I'm working on a plugin for lldb and need to scan the memory of a crashed process. Using the API to read chunks of memory and scan (via SBProcess::Read*) for what I'm looking for is easy but I haven't been able to find a way to find which address ranges are accessible. The SBProcess::Read* calls will return an error on an invalid address but it's not an efficient way to scan a 64 bit address space.
This seems like it blocks simple tasks like scanning memory for blocks allocated with a header and footer to track down memory leaks, which is crude but traditional, and ought to be pretty quick to script via the Python API. At the moment I've resorted to running a python script prior to launching my plugin that takes the output of "readelf --segments", /proc/<pid>/maps or "otool -l" but this isn't ideal. On the assumption that I'm not missing something huge I've looked at whether it is possible to extend LLDB to provide this functionality and it seems possible, there are checks protecting calls to read memory that use the data that would need to be exposed. I'm working on a prototype implementation which I'd like to deliver back at some stage but before I go too far does this sound like a good idea? Howard Hellyer IBM Runtime Technologies, IBM Systems
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
