> On May 13, 2016, at 9:13 AM, Zachary Turner <ztur...@google.com> wrote: > > 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.
This would fall out naturally if the gathering of the data is done in debugserver/lldb-server, which seems to me the natural place for this work to be done. Jim > > 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
