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