> On May 20, 2016, at 3:27 AM, Howard Hellyer <hhell...@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/ ?
Yep!
>
> 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.
Greg Clayton
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
