When using ASan and UBSan together, the common sanitizer tool name is
set to "AddressSanitizer". That means that when a UBSan diagnostic is
printed out, it looks like this:
SUMMARY: AddressSanitizer: ...
This can confuse users. Fix it so that we always use the correct tool
name when printing out UBSan diagnostics.
Differential Revision: https://reviews.llvm.org/D32066
llvm-svn: 300358
Add 'nullability_arg' and 'nullability_return' diagnostic handlers, and
also add a TypeCheckKind for null assignments to _Nonnull. With this in
place, we can update clang to use the nicer handlers for nullability
diagnostics.
The alternative to this approach is to update the existing 'nonnull_arg'
and 'nonnull_return' handlers to accept a boolean parameter. However,
versioning the existing handlers would cause code size bloat, and the
complexity cost of introducing new handlers into the runtime is low.
I will add tests for this, and all of -fsanitize=nullability, into
check-ubsan once the clang side of the changes is in.
llvm-svn: 297748
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
In Windows, when the sanitizer is implemented as a shared library (DLL), we need
an auxiliary static library dynamic_runtime_thunk that will be linked to the
main executable and dlls.
In the sanitizer DLL, we are exposing weak functions with WIN_WEAK_EXPORT_DEF(),
which exports the default implementation with __dll suffix. For example: for
sanitizer coverage, the default implementation of __sanitizer_cov_trace_cmp is
exported as: __sanitizer_cov_trace_cmp__dll.
In the dynamic_runtime_thunk static library, we include weak aliases to the
imported implementation from the dll, using the macro WIN_WEAK_IMPORT_DEF().
By default, all users's programs that include calls to weak functions like
__sanitizer_cov_trace_cmp, will be redirected to the implementation in the dll,
when linking to dynamic_runtime_thunk.
After this diff, we are able to compile code with sanitizer coverage
instrumentation on Windows. When the instrumented object files are linked with
clang-rt_asan_dynamic_runtime_thunk-arch.lib all the weak symbols will be
resolved to the implementation imported from asan dll.
All the files sanitizer_dynamic_runtime_thunk.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we compile: [asan|ubsan|sanitizer_coverage]_win_dynamic_runtime_thunk.cc
and sanitizer_win_dynamic_runtime_thunk.cc to generate
asan_dynamic_runtime_thunk.lib, because we include asan, ubsan and sanitizer
coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29158
llvm-svn: 293953
In this diff, I update current implementation of the interception in dll_thunks
to consider the special case of weak functions.
First we check if the client has redefined the function in the main executable
(for example: __sanitizer_cov_trace_pc_guard). It we can't find it, then we look
for the default implementation (__sanitizer_cov_trace_pc_guard__dll). The
default implementation is always available because the static runtime is linked
to the main executable.
Differential Revision: https://reviews.llvm.org/D29155
llvm-svn: 293952
When the sanitizer is implemented as a static library and is included in the
main executable, we need an auxiliary static library dll_thunk that will be
linked to the dlls that have instrumentation, so they can refer to the runtime
in the main executable. Basically, it uses interception to get a pointer the
function in the main executable and override its function with that pointer.
Before this diff, all of the implementation for dll_thunks was included in asan.
In this diff I split it into different sanitizers, so we can use other
sanitizers regardless of whether we include asan or not.
All the sanitizers include a file sanitizer_win_dll_thunk.cc that register
functions to be intercepted in the binary section: DLLTH
When the dll including dll_thunk is initialized, it will execute
__dll_thunk_init() implemented in: sanitizer_common/sanitizer_win_dll_thunk.cc,
which will consider all the CB registered in the section DLLTH. So, all the
functions registered will be intercepted, and redirected to the implementation
in the main executable.
All the files "sanitizer_win_dll_thunk.cc" are independent, so we don't need to
include a specific list of sanitizers. Now, we compile: asan_win_dll_thunk.cc
ubsan_win_dll_thunk.cc, sanitizer_coverage_win_dll_thunk.cc and
sanitizer_win_dll_thunk.cc, to generate asan_dll_thunk, because we include asan,
ubsan and sanitizer coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29154
llvm-svn: 293951
Add a new auxiliary file to each sanitizer: sanitizer_interface.inc, listing all
the functions exported, with the macros: INTERFACE_FUNCTION() and
INTERFACE_WEAK_FUNCTION().
So, when we need to define or repeat a procedure for each function in the
sanitizer's interface, we can define the macros and include that header.
In particular, these files are needed for Windows, in the nexts commits.
Also, this files could replace the existing files: weak_symbols.txt for Apple.
Instead of reading weak_symbols.txt to get the list of weak symbols, we could
read the file sanitizer_interface.inc and consider all the symbols included with
the macro INTERFACE_WEAK_FUNCTION(Name).
In this commit, I only include these files to the sanitizers that work on
Windows. We could do the same for the rest of the sanitizers when needed.
I updated tests for: Linux, Darwin and Windows. If a new function is exported
but is not present in the interface list, the tests
"interface_symbols_[darwin|windows|linux].c" fail.
Also, I remove the comments: "/* OPTIONAL */" which are not required any more,
because we use the macro: INTERFACE_WEAK_FUNCTION() for weak functions.
Differential Revision: https://reviews.llvm.org/D29148
llvm-svn: 293682
In this diff, I define a general macro for defining weak functions
with a default implementation: "SANITIZER_INTERFACE_WEAK_DEF()".
This way, we simplify the implementation for different platforms.
For example, we cannot define weak functions on Windows, but we can
use linker pragmas to create an alias to a default implementation.
All of these implementation details are hidden in the new macro.
Also, as I modify the name for exported weak symbols on Windows, I
needed to temporarily disable "dll_host" test for asan, which checks
the list of functions included in asan_win_dll_thunk.
Differential Revision: https://reviews.llvm.org/D28596
llvm-svn: 293419
This patch adds some useful macros for dealing with pragma directives on
Windows. Also, I add appropriate documentation for future users.
Differential Revision: https://reviews.llvm.org/D28525
llvm-svn: 292650
Summary:
The build system was inconsistent in its naming conventions for
link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS,
for consistency with cmake's LINK_FLAGS property.
This patch should make it easier to search the source code for
uses of link flags, as well as providing the benefit of improved
style and consistency.
Reviewers: compnerd, beanz
Subscribers: kubabrecka, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28506
llvm-svn: 291539
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291417
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291314
This patch starts passing architecture information about a module to llvm-symbolizer and into text reports. This fixes the longstanding x86_64/x86_64h mismatch issue on Darwin.
Differential Revision: https://reviews.llvm.org/D27390
llvm-svn: 291287
Summary: This is the compiler-rt side of D28242.
Reviewers: kcc, vitalybuka, pgousseau, gbedwell
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28244
llvm-svn: 291237
The definitions in sanitizer_common may conflict with definitions from system headers because:
The runtime includes the system headers after the project headers (as per LLVM coding guidelines).
lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT
This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry.
Differential Revision: https://reviews.llvm.org/D21947
llvm-svn: 281657
This patch builds on LLVM r279776.
In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth.
The three steps I abstract are:
(1) Add a top-level target (i.e asan, msan, ...)
(2) Set the target properties for sorting files in IDE generators
(3) Make the compiler-rt target depend on the top-level target
The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name.
The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings.
With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is:
> cmake [...]
> ninja runtimes-configure
> ninja asan
The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build.
Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats).
llvm-svn: 279863
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 279816
Summary:
On apple targets, when SANITIZER_CAN_USE_CXXABI is false,
the ubsan cxxabi sources aren't built, since they're unused.
Do this on non-apple targets as well.
This fixes errors when linking sanitizers if c++ abi is
unavailable.
Reviewers: pcc, kubabrecka, beanz
Subscribers: rnk, llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23638
llvm-svn: 279467
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278848
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278772
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278764
Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
Summary:
This CL adds a weak check for a Vtable prefix: for a well-formed
Vtable, we require the prefix to be within [-1<<20; 1<<20].
Practically, this solves most of the known cases when UBSan segfaults
without providing any useful diagnostics.
Reviewers: pcc
Subscribers: kubabrecka
Differential Revision: http://reviews.llvm.org/D19750
llvm-svn: 271560
sanitizer_common is now in good enough shape on s390x to support UBSan
- all tests passing. Let's enable it.
Differential Revision: http://reviews.llvm.org/D19157
llvm-svn: 266483
Summary:
Introducing InitializeCommonFlags accross all sanitizers to simplify
common flags management.
Setting coverage=1 when html_cov_report is requested.
Differential Revision: http://reviews.llvm.org/D18273
llvm-svn: 263820
That change did:
-#if defined(__BIG_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
If __BYTE_ORDER__ and __ORDER_BIG_ENDIAN__ aren't defined, like
they are with MSVC, this condition is true (0 == 0).
Fixes PR26919.
llvm-svn: 263324
Summary:
Use InternalScopedString more extensively. This reduces the number of
write() syscalls, and reduces the chance that UBSan output will be
mixed with program output.
Reviewers: vitalybuka
Subscribers: kcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D18068
llvm-svn: 263176
Summary:
__BIG_ENDIAN__ and __LITTLE_ENDIAN__ are not supported by gcc, which
eg. for ubsan Value::getFloatValue will silently fall through to
the little endian branch, breaking display of float values by ubsan.
Use __BYTE_ORDER__ == __ORDER_BIG/LITTLE_ENDIAN__ as the condition
instead, which is supported by both clang and gcc.
Noticed while porting ubsan to s390x.
Patch by Marcin Kościelnicki!
Differential Revision: http://reviews.llvm.org/D17660
llvm-svn: 263077
Summary:
iOS on ARM64 doesn't unique RTTI.
Ref: clang's iOS64CXXABI::shouldRTTIBeUnique()
Due to this, pointer-equality will not necessarily work in this
architecture, across dylib boundaries.
dynamic_cast<>() will (as expected) still work, since Apple ships with
one prepared for this, but we can't rely on the type names being
pointer-equal.
I've limited the expensive strcmp check to the specific architecture
which needs it.
Example which triggers this bug:
lib.h:
struct X {
virtual ~X() {}
};
X *libCall();
lib.mm:
X *libCall() {
return new X;
}
prog.mm:
int main() {
X *px = libCall();
delete px;
}
Expected output: Nothing
Actual output:
<unknown>: runtime error: member call on address 0x00017001ef50 which does not point to an object of type 'X'
0x00017001ef50: note: object is of type 'X'
00 00 00 00 60 00 0f 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for ‘X’
Reviewers: kubabrecka, samsonov, eugenis, rsmith
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D11502
llvm-svn: 262147
Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the vtable pointer against the set of all known vtable addresses and
lets the runtime handler know if it is safe to inspect the vtable.
http://reviews.llvm.org/D16824
llvm-svn: 259717
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I am the punishment of God... If [autoconf] had not committed great sins, God would not have sent a punishment like me upon [it]."
-Genghis Khan
Reviewers: chandlerc, grosbach, bob.wilson, zaks.anna, kubabrecka, samsonov, echristo
Subscribers: iains, llvm-commits
Differential Revision: http://reviews.llvm.org/D16473
llvm-svn: 258863
* add __cfi_slowpath_diag with a 3rd parameter which is a pointer to
the diagnostic info for the ubsan handlers.
*__cfi_check gets a 3rd parameter as well.
* unify vcall/cast/etc and icall diagnostic info format, and merge
the handlers to have a single entry point (actually two points due
to abort/noabort variants).
* tests
Note that this comes with a tiny overhead in the non-diag mode:
cfi_slowpath must pass 0 as the 3rd argument to cfi_check.
llvm-svn: 258744
Summary:
Add the ability to suppress UBSan reports for files/functions/modules
at runtime. The user can now pass UBSAN_OPTIONS=suppressions=supp.txt
with the contents of the form:
signed-integer-overflow:file-with-known-overflow.cpp
alignment:function_doing_unaligned_access
vptr:shared_object_with_vptr_failures.so
Suppression categories match the arguments passed to -fsanitize=
flag (although, see below). There is no overhead if suppressions are
not provided. Otherwise there is extra overhead for symbolization.
Limitations:
1) sometimes suppressions need debug info / symbol table to function
properly (although sometimes frontend generates enough info to
do the match).
2) it's only possible to suppress recoverable UB kinds - if you've
built the code with -fno-sanitize-recover=undefined, suppressions
will not work.
3) categories are fine-grained check kinds, not groups like "undefined"
or "integer", so you can't write "undefined:file_with_ub.cc".
Reviewers: rsmith, kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15363
llvm-svn: 256018
Summary:
Rather than having to add new "experimental" options each time someone wants to work on bringing a sanitizer to a new platform, this patch makes options for all of them.
The default values for the options are set by the platform checks that would have enabled them, but they can be overridden on or off.
Reviewers: kubabrecka, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14846
llvm-svn: 255170
Let unrecoverable handlers be responsbile for killing the
program with Die(), and let functions which print the error
report know if it's going to happen. Re-write the comments to
describe the situation.
llvm-svn: 255081
Currently, this is an NFC. However, knowing out the kind of error
report before we bring up all the reporting machinery (implemented in
ScopedReport class) is important once we teach UBSan runtime
suppressions.
llvm-svn: 255074
This reverts commit r250823.
Replacing at least some of empty
constructors with "= default" variants is a semantical change which we
don't want. E.g. __tsan::ClockBlock contains a union of large arrays,
and it's critical for correctness and performance that we don't memset()
these arrays in the constructor.
llvm-svn: 251717
If the pointer passed to the getVtablePrefix function was read from a freed
object, we may end up following pointers into objects on the heap and
printing bogus dynamic type names in diagnostics. However, we know that
vtable pointers will generally only point into memory mapped from object
files, not objects on the heap.
This change causes us to only follow pointers in a vtable if the vtable
and one of the virtual functions it points to appear to have appropriate
permissions (i.e. non-writable, and maybe executable), which will generally
exclude heap pointers.
Only enabled for Linux; this hasn't been tested on FreeBSD, and vtables are
writable on Mac (PR24782) so this won't work there.
Differential Revision: http://reviews.llvm.org/D12790
llvm-svn: 247484
Summary:
This is another step in a multi-step refactoring to move add_sanitizer_rt_symbols in the direction of other add_* functions in compiler-rt.
Changes to CMakeLists files are all minimal except ubsan which tests the new ARCHS loop.
Further cleanup patches will follow.
Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12410
llvm-svn: 246199
Summary: This is another step in a multi-step refactoring to move add_sanitizer_rt_symbols in the direction of other add_* functions in compiler-rt.
Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12409
llvm-svn: 246178
Summary: This is the first step in a multi-step refactoring to move add_sanitizer_rt_symbols in the direction of other add_* functions in compiler-rt.
Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12386
llvm-svn: 246102
Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists.
This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features.
Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov
Subscribers: beanz, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D12292
llvm-svn: 245970
Summary: This patch consolidates add_compiler_rt_osx_static_runtime and add_compiler_rt_darwin_dynamic_runtime into a single new function add_compiler_rt_darwin_runtime.
Reviewers: filcab, samsonov, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12106
llvm-svn: 245317
Summary:
Let UBSan output flag description if 'help' options is provided.
Report unrecognized flags if verbosity mode is turned on.
Patch by Svetlana Ryabkova!
Differential Revision: http://reviews.llvm.org/D11903
llvm-svn: 244946
Summary:
Compiler-rt part of http://reviews.llvm.org/D11757
I ended up making UBSan work with both the old version and the new
version of the float_cast_overflow data (instead of just erroring with
the previous version). The old version will try to symbolize its caller.
Now we compile the float_cast_overflow tests without -g, and make sure
we have the source file+line+column.
If you think I'm trying too hard to make sure we can still use both
versions, let me know.
Reviewers: samsonov, rsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11793
llvm-svn: 244567
Offset from vptr to the start of most-derived object can actually
be positive in some virtual base class vtables.
Patch by Stephan Bergmann!
llvm-svn: 244101
This fixes the bug https://llvm.org/bugs/show_bug.cgi?id=24152
The float value resides in the first 4 bytes of ValueHandle for both mips and mipsel.
Reviewers: dsanders, samsonov
Subscibers: rsmith, hans, mohit.bhakkad, jaydeep, llvm-commits
Differential: http://reviews.llvm.org/D11448
llvm-svn: 243384
The image-relative complete object locator contains a reference to itself,
which we can use to compute the image base without using VirtualQuery.
Spotted by David Majnemer.
llvm-svn: 241758
Specifically:
- Start using %expect_crash.
- Provide an implementation of __ubsan::getDynamicTypeInfoFromVtable
for the Microsoft C++ ABI. This is all that is needed for CFI
diagnostics; UBSan's -fsanitize=vptr also requires an implementation of
__ubsan::checkDynamicType.
- Build the sanitizer runtimes against the release version of the C
runtime, even in debug builds.
- Accommodate demangling differences in tests.
Differential Revision: http://reviews.llvm.org/D11029
llvm-svn: 241745
Summary:
This patch implements step 1 from
https://llvm.org/bugs/show_bug.cgi?id=23539#c10
I'd appreciate if you could test it on Mac OS and verify that parts of UBSan
runtime that reference C++ ABI symbols are properly excluded, and fix ASan/UBSan
builds.
Test Plan: regression test suite
Reviewers: thakis, hans
Subscribers: llvm-commits, zaks.anna, kubabrecka
Differential Revision: http://reviews.llvm.org/D10621
llvm-svn: 240617
Summary:
Use CMake's cmake_parse_arguments() instead.
It's called in a slightly different way, but supports all our use cases.
It's in CMake 2.8.8, which is our minimum supported version.
CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc):
http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments
Since I was already changing these calls, I changed ARCH and LIB into
ARCHS and LIBS to make it more clear that they're lists of arguments.
Reviewers: eugenis, samsonov, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10529
llvm-svn: 240120
Summary:
This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library.
The goal of this is to try to push platform handling as low in the utility functions as possible.
Reviewers: rnk, samsonov
Reviewed By: rnk, samsonov
Subscribers: rnk, rsmith, llvm-commits
Differential Revision: http://reviews.llvm.org/D10250
llvm-svn: 239498
Summary:
With this patch, we have a flag to toggle displaying source locations in
the regular style:
file:line:column
or Visual Studio style:
file(line,column)
This way, they get picked up on the Visual Studio output window and one
can double-click them to get to that file location.
Reviewers: samsonov, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10113
llvm-svn: 239000
float-cast-overflow handler doesn't have source location provided by the
compiler, but we still have *some* source location if we have a
symbolizer.
llvm-svn: 235567
As with the other sanitizers, it is desirable to allow ubsan's output to be
redirected to somewhere other than stderr (and into per-process log files).
llvm-svn: 235277
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix \
-format
llvm-svn: 234680
Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change
doesn't modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, rsmith, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8646
llvm-svn: 233861
One test case is updated to allow for differences between power and other architectures in behavior when returning from main in certain instances
http://reviews.llvm.org/D8743
llvm-svn: 233813
This change caused test failures on darwin, and the followup which was
meant to fix those caused compiler-rt to start failing to link.
Reverting to get the build working again.
This reverts r233071 and r233036.
llvm-svn: 233097
Summary:
Switch to shared library for UBSan. Add support for building
UBSan on OSX and iossim by cargo-culting ASan build rules.
Test Plan: regression test suite
Reviewers: zaks.anna, kubabrecka
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8473
llvm-svn: 233036
Get rid of "libclang_rt.san" library that used to contain
sanitizer_common pieces required by UBSan if it's used in a standalone
mode. Instead, build two variants of UBSan runtime: "ubsan" and
"ubsan_standalone" (same for "ubsan_cxx" and "ubsan_standalone_cxx").
Later "ubsan" and "ubsan_cxx" libraries will go away, as they will
embedded it into corresponding ASan runtimes.
llvm-svn: 233011
Nico Weber