[Lldb-commits] [PATCH] D21751: Implement GetMemoryRegions() for Linux and Mac OSX core files.

[Greg Clayton via lldb-commits]

clayborg added a comment.



In http://reviews.llvm.org/D21751#468738, @hhellyer wrote:

> Since there’s a list of memory regions already created in the Process implementations for the core fles I thought it made sense just to use that directly, at least when reading from a core file. It meant there was no requirement to change those GetMemoryRegionInfo implementations if they didn’t behave quite the same. That said it is roughly what I planned to do for the live connections as the behaviour of the qMemoryRegionInfo query is more tightly specified and moving to that model would just push that implementation one layer higher.


We should document the Process::GetMemoryRegionInfo() and what we expect of it so that all plug-ins implement it correctly.

> I will push a revision which follows the approach you suggest, if we find that throws up it’s own problems then I can always revert. As I mentioned the remote connections should (hopefully) all work with that pattern so GetMemoryRegions implemented in fewer commits with that approach.


Indeed. Since we already expect a behavior from Process::GetMemoryRegionInfo(), I would say lets enforce these requirements by making Process::GetMemoryRegions() just use that API as required. The only time we should see an error from Process::GetMemoryRegionInfo() is when it isn't implemented.

> Is PAGEZERO actually included in Mac core dumps? I can see it as load command 0 when I run otool against an executable but when I look at a core dump from the same executable the first load command looks like load command 1 in the executable. There doesn’t seem to be a load command in the core for address 0. I might just be missing an flag on otool though.


It might not be, but that brings up another thing I was thinking of is that we could start supplementing the Process::GetMemoryRegionInfo() info by also looking in any sections that were found in core file memory that might not be fully described by the core file itself. There is no requirements that if two sections are adjacent in a core file that they show up as different mapped regions, so you might find a mapped section of memory from 0x1000-0x8000 that is actually 0x1000-0x4000 for ".data" and 0x4000-0x8000 that is ".bss". The memory region was mapped read+write, but would it be nice to know about these different regions separately? We don't need to do this now, but this is one place where we could figure out that 0x0-0x100000000 is __PAGEZERO even though it isn't mapped into the current mach-o file's memory regions. Also there are different makers of core files: lldb, the kernel, possibly others. They don't always follow the same rules when making mach-o core files. So it is nice to be flexible.


http://reviews.llvm.org/D21751