Oh, that's a cute trick, but it relies on the not (at-least-to-me) obvious fact
that an address in an unmapped region will return the extents of the unmapped
region. For it to be useful, that needs to be a requirement of the API's
implementation.
It seems to me it would be much clearer to have an API that returns the memory
regions for you.
Jim
> On May 12, 2016, at 11:09 AM, Greg Clayton via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> 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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
