On Intel processors, the best way to do this is probably going to be to walk the page directory (see Intel processor manuals). Assuming someone implements this command in lldb, I hope it can be done in such a way as to allow different implementations when one os/architecture has a better way of doing it.
On Thu, May 12, 2016 at 11:09 AM Jim Ingham via lldb-dev < lldb-dev@lists.llvm.org> wrote: > You should be able to enumerate the memory that is occupied by loaded > executables, by getting the list of loaded Modules from the target, and > iterate through the all the Sections. The Sections know their loaded > locations. I assume all the mapped ones will return a valid load address > from GetLoadBaseAddress, so you can distinguish the loaded and unloaded > ones. So you shouldn't need "readelf --segments" or "otool -l", lldb > should know this. > > You can scan the currently active stacks, but we don't currently know the > allocated stack extents, just what is being used. It would be interesting > to know the actual stack extents, so you could search in old stacks and to > know if you are close to exhausting the stack of a thread. > > We don't have either a generic API, or internal implementations, for > getting all the mapped memory regions (or shared pages) of processes. That > would be quite useful. IIRC ptr_refs does this by injecting some code into > the target program that enumerates the regions. Greg would know more about > this. Most systems provide some API to get at this that works > cross-process, but that doesn't help debugging remotely. So we either need > to teach debugserver & lldb-server to do this, or use appropriate code > injection. The gdb-remote protocol has a query for the "memory map" of the > process, though this is more tailored to identify things like memory mapped > registers. Still it might be possible to use this as well. > > It would be nice to be able to separately query heap, executable & stack > memory as well. Though a properly annotated memory map would give you a > way to do this, so that could be layered on top. > > Jim > > > On May 12, 2016, at 6:20 AM, Howard Hellyer via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > 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 > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
