[lldb-dev] Listing memory regions in lldb

[Howard Hellyer via lldb-dev]

>> - Using GetMemoryRegionInfo to iterate might be quite expensive if 
there are many small memory regions.
> 
> Remember that the other use for GetMemoryRegionInfo() might be a user 
just asking about an address they have in a register or variable that is a 
pointer. So if we do add a more complex iteration scheme, feel free to do 
so, but please leave the call that ask about a single address intact so it 
can be used by clients

Yep, that's sensible. It gives a user an easy way to check things like 
"Does this char* really point to an area of writable memory?"

>> - Using GetMemoryRegionInfo over a remote connection on Linux and Mac 
worked well but seemed to coalesce some of the memory regions together.
> 
> You might want to add an extra parameter to not coalesce regions. Or if 
we start adding names to the memory regions (".text", ".data") or types 
(stack, heap, section from a file, guard page) then we might just start 
not coalescing the regions so we can see these differences. Or we can add 
more options to the API:

This may not be an issue. After a bit more digging I think it might be 
safer to have individual Process plug-ins implement 
GetMemoryRegionInfoList directly and they can use the GetMemoryRegionInfo 
iteration pattern if it's safe.

> SBMemoryRegionInfoList SBTarget::GetMemoryRegions(bool coalesce);

> Hopefully my comments have provided some insight. Let me know what you 
come up with.

I agree the SBMemoryRegionInfoList approach makes the most sense, it's 
much safer.

I think in my prototyping the main difference is that I've put 
GetMemoryRegions/GetMemoryRegionInfo on SBProcess simply because that's 
where the internal GetMemoryRegions/GetMemoryRegionInfo functions it calls 
are but I'm happy with either if you have a preference.

I'm assuming the best way forward is to submit patches is via 
http://reviews.llvm.org/ ?

Rather than submit a monolithic one is I was going to submit one for the 
SB API changes first, calling 
lldb_private::Process::GetMemoryRegionInfoList with that having a default 
unsupported impl like lldb_private::Process::GetMemoryRegionInfo.

After that I can submit patches to fill in 
lldb_private::Process::GetMemoryRegionInfoList (and GetMemoryRegionInfo 
where's it's missing) on a per platform basis. (The alternative was to 
start with a command that exploits the new Process API for listing regions 
and work out from there, down into the process plug-ins and up into the SB 
API.)

Let me know if there's a better way to do this!

Howard Hellyer
IBM Runtime Technologies, IBM Systems 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160520/8845b989/attachment.html>