Summary:
This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86.
It is currently based on Solaris 11.4 Beta.
This part was initially developed inside libsanitizer in the GCC tree and should apply to
both. Subsequent parts will address changes to clang, the compiler-rt build system
and testsuite.
I'm not yet sure what the right patch granularity is: if it's profitable to split the patch
up, I'd like to get guidance on how to do so.
Most of the changes are probably straightforward with a few exceptions:
* The Solaris syscall interface isn't stable, undocumented and can change within an
OS release. The stable interface is the libc interface, which I'm using here, if possible
using the internal _-prefixed names.
* While the patch primarily target 32-bit x86, I've left a few sparc changes in. They
cannot currently be used with clang due to a backend limitation, but have worked
fine inside the gcc tree.
* Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit
Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that.
The patch (with the subsequent ones to be submitted shortly) was tested
on i386-pc-solaris2.11. Only a few failures remain, some of them analyzed, some
still TBD:
AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations
Maybe this is good enough the get the ball rolling.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40898
llvm-svn: 320740
Unreverting this patch because llvm-clang-lld-x86_64-debian-fast started
passing again before the revert hit. Must've been just a flake.
llvm-svn: 314556
Summary:
Adds a fallback mode to procmaps when the symbolizer
fails to locate a module for a given address by using
dl_iterate_phdr.
Reviewers: kubamracek, rnk, vitalybuka, eugenis
Reviewed By: eugenis
Subscribers: srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D37269
llvm-svn: 314431
Summary:
Platforms that don't implement procmaps (primarily fuchsia and windows) still expose
the procmaps API when including sanitizer_procmaps.h, despite not implementing the functions
provided by that header. Ensure that the API is only exposed on platforms that implement it.
Reviewers: vitalybuka, alekseyshl, kubamracek
Subscribers: llvm-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D38187
llvm-svn: 314149
Summary:
This is a re-upload of the reverted commit r308644. It has changed quite
a bit to reflect post-commit comments by kcc, so I'm re-uploading as
a new review.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35799
llvm-svn: 308977
Summary: This will allow sanitizer_procmaps on mac to expose section information.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35422
llvm-svn: 308644
Summary:
Reuse Linux and FreeBSD - no NetBSD specific changes.
Part of the code inspired by the original work on libsanitizer in GCC 5.4 by Christos Zoulas.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, filcab, kcc, vitalybuka
Reviewed By: filcab
Subscribers: llvm-commits, emaste, kubamracek, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D35629
llvm-svn: 308615
Summary:
__DATA segments on Darwin contain a large number of separate sections,
most of which cannot actually contain pointers, and contain const values or
objc metadata. Only scanning sections which can contain pointers greatly improves
performance.
On a medium-sized (~4000 files) internal project, I saw a speedup of about 50%
in standalone LSan's execution time (50% improvement in the time spent running
LSan, not the total program time).
Reviewers: kcc, kubamracek, alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35432
llvm-svn: 308231
Summary: This will allow sanitizer_procmaps on mac to expose section information.
Reviewers: kubamracek, alekseyshl, kcc
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35422
llvm-svn: 308210
Summary:
This function is only called once and is fairly simple. Inline to
keep API simple.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35270
llvm-svn: 307695
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
llvm-svn: 307688
Summary:
Sanitizer procmaps uses dyld apis to iterate over the list of images
in the process. This is much more performan than manually recursing
over all of the memory regions in the process, however, dyld does
not report itself in the list of images. In order to prevent reporting
leaks from dyld globals and to symbolize dyld functions in stack traces,
this patch special-cases dyld and ensures that it is added to the
list of modules.
This is accomplished by recursing through the memory map of the process
until a dyld Mach header is found. While this recursion is expensive,
it is run before the full set of images has been loaded in the process,
so only a few calls are required. The result is cached so that it never
needs to be searched for when the full process memory map exists, as this
would be incredibly slow, on the order of minutes for leak sanitizer with
only 25 or so libraries loaded.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32968
llvm-svn: 302899
This breaks several tests because we don't always have
access to __cxa_guard functions
This reverts commit 45eb470c3e9e8f6993a204e247c33d4092237efe.
llvm-svn: 302693
Summary:
Sanitizer procmaps uses dyld apis to iterate over the list of images
in the process. This is much more performan than manually recursing
over all of the memory regions in the process, however, dyld does
not report itself in the list of images. In order to prevent reporting
leaks from dyld globals and to symbolize dyld functions in stack traces,
this patch special-cases dyld and ensures that it is added to the
list of modules.
This is accomplished by recursing through the memory map of the process
until a dyld Mach header is found. While this recursion is expensive,
it is run before the full set of images has been loaded in the process,
so only a few calls are required. The result is cached so that it never
needs to be searched for when the full process memory map exists, as this
would be incredibly slow, on the order of minutes for leak sanitizer with
only 25 or so libraries loaded.
Reviewers: alekseyshl, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32968
llvm-svn: 302673
This patch adds tracking which modules are instrumented and which are not. On macOS, instrumented modules link against the ASan/TSan/... dylib, so we can just check if such a load command exists or not.
Differential Revision: https://reviews.llvm.org/D28263
llvm-svn: 291268
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
Summary:
This removes the hard limit on the number of loaded modules (used to be
16K), and makes it easier to use LoadedModules w/o causing a memory
leak: ListOfModules owns the modules, and makes sure to properly clean
them in destructor.
Remove filtering functionality that is only needed in one place (LSan).
Reviewers: aizatsky
Subscribers: llvm-commits, kcc
Differential Revision: http://reviews.llvm.org/D17470
llvm-svn: 261554
from /proc/self/maps.
The mappings are currently being cached on each access to /proc/self/maps. In the future we'll need to add an API that allows the client to notify ASan about the sandbox.
llvm-svn: 169076
Kamil Rytarowski