[lldb-dev] Listing memory regions in lldb

[Greg Clayton via lldb-dev]

We have a way internally with:

    virtual Error
    lldb_private::Process::GetMemoryRegionInfo (lldb::addr_t load_addr, MemoryRegionInfo &range_info);

This isn't expose via the public API in lldb::SBProcess. If you want, you can expose this. We would need to expose a SBMemoryRegionInfo and the call could be:

namespace lldb
{
    class SBProcess
    {
        SBError GetMemoryRegionInfo (lldb::addr_t load_addr, SBMemoryRegionInfo &range_info);
    };
}

then you would call this API with address zero and it would return a SBMemoryRegionInfo with an address range and if that memory is read/write/execute. On MacOSX we always have a page zero at address 0 for 64 bit apps so it would respond with:

[0x0 - 0x100000000) read=false, write=false, execute=false

Then you call the function again with the end address of the previous range. 

I would love to see this functionality exported through our public API. Let me know if you are up for making a patch. If you are, you might want to quickly read the following web page to see the rules that we apply to anything going into our public API:

http://lldb.llvm.org/SB-api-coding-rules.html


Greg

> 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