[lldb-dev] Listing memory regions in lldb

[Jim Ingham via lldb-dev]

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