[lldb-dev] Listing memory regions in lldb

[Zachary Turner via lldb-dev]

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>