[PATCH] D26632: [sanitizer] Track architecture and UUID of modules in LoadedModule

[Kuba Brecka via llvm-commits]

kubabrecka created this revision.
kubabrecka added reviewers: dvyukov, kcc, zaks.anna, eugenis.
kubabrecka added a subscriber: llvm-commits.
kubabrecka set the repository for this revision to rL LLVM.
kubabrecka added a project: Sanitizers.
Herald added a subscriber: emaste.

When we enumerate loaded modules, we only track the module name and base address, which then has several problems on macOS.  Dylibs and executables often have several architecture slices and not storing which architecture/UUID is actually loaded creates problems with symbolication:  A file path + offset isn't enough to correctly symbolicate, since the offset can be valid in multiple slices.  This is especially common for Haswell+ X86_64 machines, where x86_64h slices are preferred, but if one is not available, a regular x86_64 is loaded instead.  But the same issue exists for i386 vs. x86_64 as well.

This patch adds tracking of arch and UUID for each LoadedModule.  At this point, this information isn't used in reports, but this is the first step.  The goal is to correctly identify which slice is loaded in symbolication, and also to output this information in reports so that we can tell which exact slices were loaded in post-mortem analysis.


Repository:
  rL LLVM

https://reviews.llvm.org/D26632

Files:
  lib/sanitizer_common/sanitizer_common.cc
  lib/sanitizer_common/sanitizer_common.h
  lib/sanitizer_common/sanitizer_procmaps.h
  lib/sanitizer_common/sanitizer_procmaps_freebsd.cc
  lib/sanitizer_common/sanitizer_procmaps_linux.cc
  lib/sanitizer_common/sanitizer_procmaps_mac.cc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D26632.77867.patch
Type: text/x-patch
Size: 11201 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161114/7a1e2905/attachment.bin>