[lldb-dev] Listing memory regions in lldb

Zachary Turner via lldb-dev lldb-dev at lists.llvm.org
Fri May 13 09:13:45 PDT 2016

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 at 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 at 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 at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160513/2368d975/attachment.html>

More information about the lldb-dev mailing list