diff options
| author | Kuba Mracek <mracek@apple.com> | 2016-12-02 21:27:14 +0000 |
|---|---|---|
| committer | Kuba Mracek <mracek@apple.com> | 2016-12-02 21:27:14 +0000 |
| commit | 3eb98a13183703c36cc481189e1b362d7077a9b4 (patch) | |
| tree | 4aed166a7609c5a6edab16cee82af363e1fbd41c /libcxx/test/std/utilities/variant/variant.variant/variant.assign/copy.pass.cpp | |
| parent | 96be8df23ef2eb47631fc24481d76a19899cd7ee (diff) | |
| download | bcm5719-llvm-3eb98a13183703c36cc481189e1b362d7077a9b4.tar.gz bcm5719-llvm-3eb98a13183703c36cc481189e1b362d7077a9b4.zip | |
[sanitizer] Track architecture and UUID of modules in LoadedModule
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.
Differential Revision: https://reviews.llvm.org/D26632
llvm-svn: 288537
Diffstat (limited to 'libcxx/test/std/utilities/variant/variant.variant/variant.assign/copy.pass.cpp')
0 files changed, 0 insertions, 0 deletions
