<font size=3>>> - Using GetMemoryRegionInfo to iterate might be
quite expensive if there are many small memory regions.<br>
> <br>
> 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<br>
<br>
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?"<br>
<br>
>> - Using GetMemoryRegionInfo over a remote connection on Linux
and Mac worked well but seemed to coalesce some of the memory regions together.<br>
> <br>
> 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:<br>
<br>
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.<br>
<br>
> SBMemoryRegionInfoList SBTarget::GetMemoryRegions(bool coalesce);<br>
<br>
> Hopefully my comments have provided some insight. Let me know what
you come up with.<br>
<br>
I agree the SBMemoryRegionInfoList approach makes the most sense, it's
much safer.<br>
<br>
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.<br>
<br>
I'm assuming the best way forward is to submit patches is via </font><a href=http://reviews.llvm.org/><font size=3 color=blue>http://reviews.llvm.org/</font></a><font size=3>
?<br>
<br>
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.<br>
<br>
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.)<br>
<br>
Let me know if there's a better way to do this!<br>
<br>
Howard Hellyer<br>
IBM Runtime Technologies, IBM Systems </font>