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@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
