[PATCH] D35422: Add MemoryMappedSection struct for two-level memory map iteration

Francis Ricci via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 14 14:15:23 PDT 2017


fjricci added inline comments.


================
Comment at: lib/sanitizer_common/sanitizer_procmaps.h:67
   u8 uuid[kModuleUUIDSize];
+  bool has_sections;
 };
----------------
alekseyshl wrote:
> Is it possible to drop has_sections and MemoryMappedSection, and add the current section info right here, under #if MAC? No other but Mac specific code will need to be changed.
> 
> If it turns out to be beneficial to have MemoryMappedSection defined, well, maybe define it inside the MemoryMappedSegment, under the same #if and call it just Segment?
> 
> That would lead to a platform specific function AddSegmentAddressRange(MemoryMappedSegment *segment, LoadedModule *module); and all the Mac specific stuff will be contained in _mac files.
> 
> What do you think? It's totally possible I miss some details precluding us from doing so.
Hmm, I'm not sure I completely understand what you mean. The reason why the MemoryMappedSection is a separate struct is because each MemoryMappedSegment will have multiple MemoryMappedSection's (at least on Darwin), so there isn't a 1:1 correspondence. The MemoryMappedSection is also quite a bit lighter-weight/smaller than using a full MemoryMappedSegment struct for each section.

I'm alright with moving Section inside of MemoryMappedSegment.

I thought about making the MemoryMappedSection Darwin-specific (and I'm still open to it), but that will cause issues if we ever end up with non-platform specific code that needs to iterate at the level of a section (something like tsan etc). I *think* that this shouldn't ever happen, because any code that can tell the difference between a section and a segment will probably be mac-specific code by definition.


https://reviews.llvm.org/D35422





More information about the llvm-commits mailing list