[lldb-dev] Listing memory regions in lldb
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Fri May 20 10:45:24 PDT 2016
> On May 20, 2016, at 3:27 AM, Howard Hellyer <HHELLYER at uk.ibm.com> wrote:
> >> - 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.
On SBProcess is fine.
> 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!
Either way, doesn't matter to me.
I look forward to seeing your patch.
More information about the lldb-dev