I have experimented with the GetMemoryRegionInfo approach on the internal
APIs already, it has some positives and negatives.
- GetMemoryRegionInfo is unimplemented for Linux and Mac core dumps.
That's not necessarily a bad thing as it could be implemented the "right"
way. (As Jim said GetMemoryRegionInfo would have to return the right thing
for an unmapped region.) Interestingly when I've worked on Windows core
dumps before I've seen that MiniDump, with the right flags, will
deliberately insert a region in the middle of the memory ranges to
represent the unmapped space, on 64 bit it's quite a large section.
- Using GetMemoryRegionInfo to iterate might be quite expensive if there
are many small memory regions.
- One reason I hadn't looked at just exposing an SBGetMemoryRegionInfo is
that it wouldn't match a lot of the SB API's at the moment (for example
for Threads and Sections) which tend work by having GetNumXs() and
GetXAtIndex() calls. Iterating with SBGetMemoryRegionInfo would be
non-obvious to the user of the API since it doesn't match the convention.
It would need to be documented in the SBGetMemoryRegionInfo API.
- I've found the only way to reliably filter out inaccessible memory is to
do a test read and check the error return code. I'm pretty sure I've seen
some that are readable via a memory read but marked read=false,
write=false, execute=false. (I can't remember the exact case now off the
top of my head, but I think it might have been allocated but uncommitted
memory or similar.)
- Using GetMemoryRegionInfo over a remote connection on Linux and Mac
worked well but seemed to coalesce some of the memory regions together. It
also only allows for read/write/exec attributes to be passed. That's a
shame as a live process can often tell you more about what the region is
for. The remote command memory map looks like it sends back XML so it
might be possible to insert custom properties in there to give more
information but I'm not sure how safe it is to do that, I don't know the
project quite well enough to understand all the use cases for the
protocol.
- Extended infomation /proc/pid/maps marking a region as [stack] would be
lost. All you would get is read/write/exec info. (That said supporting
everything every platform can provide might be a bit much.)
- LLDB's ReadMemory implementations seem to return 0's for missing memory
that should be accessible. It might be nice to include whether the memory
is backed by real data or not in the API. (For example Linux core files
can be missing huge pages depending on the setting of
/proc/PID/coredump_filter or files can simply be truncated.)
I could implement the GetMemoryRegionInfo iteration mechanism pretty
quickly and it would actually fit my purposes as far as providing all the
addresses you can sensibly access.
I'm quite keen to provide a patch but don't want to provide one that is at
odds with how the rest of lldb works or provides data that's only useful
to me so I'm quite keen to get a bit of feedback on what the preferred
approach would be. It could be that providing both SBGetMemoryRegionInfo
and the SBGetNumMemoryRegions/SBGetMemoryRegionAtIndex pair is the right
solution.
Would a patch also need to provide a command to dump this information as
it can be awkward to have data that's only accessible via the API?
Howard Hellyer
IBM Runtime Technologies, IBM Systems
Greg Clayton <gclay...@apple.com> wrote on 12/05/2016 19:09:49:
> From: Greg Clayton <gclay...@apple.com>
> To: Howard Hellyer/UK/IBM@IBMGB
> Cc: lldb-dev@lists.llvm.org
> Date: 12/05/2016 19:10
> Subject: Re: [lldb-dev] Listing memory regions in lldb
>
> 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-
> d...@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
