Age | Commit message (Collapse) | Author |
|
Summary: Removed platform-specific ifdefs for linux, mac, freebsd and netbsd from sanitizer_procmaps.h
Patch by Yicheng Wang <yichengfb@fb.com>
Reviewers: kcc, kubamracek, alekseyshl, fjricci, vitalybuka
Reviewed By: fjricci, vitalybuka
Subscribers: vitalybuka, emaste, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D38098
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This adds NetBSD specific:
- ReadProcMaps()
- MemoryMappingLayout::Next()
This code is largely shared with FreeBSD.
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: kcc, joerg, filcab, vitalybuka, fjricci
Reviewed By: fjricci
Subscribers: emaste, kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35551
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@310116 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parameters. NFC.
Summary:
This is the first in a series of patches to refactor sanitizer_procmaps
to allow MachO section information to be exposed on darwin.
In addition, grouping all segment information in a single struct is
cleaner than passing it through a large set of output parameters, and
avoids the need for annotations of NULL parameters for unneeded
information.
The filename string is optional and must be managed and supplied by the
calling function. This is to allow the MemoryMappedSegment struct to be
stored on the stack without causing overly large stack sizes.
Reviewers: alekseyshl, kubamracek, glider
Subscribers: emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D35135
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@307688 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@288537 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: http://reviews.llvm.org/D4807
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@215185 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: http://reviews.llvm.org/D4555
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@214955 91177308-0d34-0410-b5e6-96231b3b80d8
|