>> - 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 _______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
