History log of /llvm-project/llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp (Results 76 – 100 of 165)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# b050c7fb 11-Apr-2017 Diana Picus <diana.picus@linaro.org>

Revert "Turn some C-style vararg into variadic templates"

This reverts commit r299925 because it broke the buildbots. See e.g.
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008

ll

Revert "Turn some C-style vararg into variadic templates"

This reverts commit r299925 because it broke the buildbots. See e.g.
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008

llvm-svn: 299928

show more ...


# 5fd75fb7 11-Apr-2017 Serge Guelton <sguelton@quarkslab.com>

Turn some C-style vararg into variadic templates

Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.

From a user prospective, it forces the use of an annoying nullptr

Turn some C-style vararg into variadic templates

Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.

From a user prospective, it forces the use of an annoying nullptr
to mark the end of the vararg, and there's not type checking on the
arguments. The variadic template is an obvious solution to both
issues.

llvm-svn: 299925

show more ...


# db11fdfd 06-Apr-2017 Mehdi Amini <mehdi.amini@apple.com>

Revert "Turn some C-style vararg into variadic templates"

This reverts commit r299699, the examples needs to be updated.

llvm-svn: 299702


# 579540a8 06-Apr-2017 Mehdi Amini <mehdi.amini@apple.com>

Turn some C-style vararg into variadic templates

Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.

From a user prospective, it forces the use of an annoying nullptr

Turn some C-style vararg into variadic templates

Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.

From a user prospective, it forces the use of an annoying nullptr
to mark the end of the vararg, and there's not type checking on the
arguments. The variadic template is an obvious solution to both
issues.

Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu>

Differential Revision: https://reviews.llvm.org/D31070

llvm-svn: 299699

show more ...


# b518054b 21-Mar-2017 Reid Kleckner <rnk@google.com>

Rename AttributeSet to AttributeList

Summary:
This class is a list of AttributeSetNodes corresponding the function
prototype of a call or function declaration. This class used to be
called ParamAttr

Rename AttributeSet to AttributeList

Summary:
This class is a list of AttributeSetNodes corresponding the function
prototype of a call or function declaration. This class used to be
called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is
typically accessed by parameter and return value index, so
"AttributeList" seems like a more intuitive name.

Rename AttributeSetImpl to AttributeListImpl to follow suit.

It's useful to rename this class so that we can rename AttributeSetNode
to AttributeSet later. AttributeSet is the set of attributes that apply
to a single function, argument, or return value.

Reviewers: sanjoy, javed.absar, chandlerc, pete

Reviewed By: pete

Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits

Differential Revision: https://reviews.llvm.org/D31102

llvm-svn: 298393

show more ...


Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3
# 8eb1a485 15-Feb-2017 Arnold Schwaighofer <aschwaighofer@apple.com>

ThreadSanitizer: don't track swifterror memory addresses

They are register promoted by ISel and so it makes no sense to treat them as
memory.

Inserting calls to the thread sanitizer would also gene

ThreadSanitizer: don't track swifterror memory addresses

They are register promoted by ISel and so it makes no sense to treat them as
memory.

Inserting calls to the thread sanitizer would also generate invalid IR.

You would hit:

"swifterror value can only be loaded and stored from, or as a swifterror
argument!"

llvm-svn: 295215

show more ...


Revision tags: llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1
# ddfdba3b 14-Nov-2016 Kuba Brecka <kuba.brecka@gmail.com>

[tsan] Add support for C++ exceptions into TSan (call __tsan_func_exit during unwinding), LLVM part

This adds support for TSan C++ exception handling, where we need to add extra calls to __tsan_func

[tsan] Add support for C++ exceptions into TSan (call __tsan_func_exit during unwinding), LLVM part

This adds support for TSan C++ exception handling, where we need to add extra calls to __tsan_func_exit when a function is exitted via exception mechanisms. Otherwise the shadow stack gets corrupted (leaked). This patch moves and enhances the existing implementation of EscapeEnumerator that finds all possible function exit points, and adds extra EH cleanup blocks where needed.

Differential Revision: https://reviews.llvm.org/D26177

llvm-svn: 286893

show more ...


# 3c437378 11-Nov-2016 Anna Zaks <ganna@apple.com>

[tsan][llvm] Implement the function attribute to disable TSan checking at run time

This implements a function annotation that disables TSan checking for the
function at run time. The benefit over at

[tsan][llvm] Implement the function attribute to disable TSan checking at run time

This implements a function annotation that disables TSan checking for the
function at run time. The benefit over attribute((no_sanitize("thread")))
is that the accesses within the callees will also be suppressed.

The motivation for this attribute is a guarantee given by the objective C
language that the calls to the reference count decrement and object
deallocation will be synchronized. To model this properly, we would need
to intercept all ref count decrement calls (which are very common in ObjC
due to use of ARC) and also every single message send. Instead, we propose
to just ignore all accesses made from within dealloc at run time. The main
downside is that this still does not introduce any synchronization, which
means we might still report false positives if the code that relies on this
synchronization is not executed from within dealloc. However, we have not seen
this in practice so far and think these cases will be very rare.

Differential Revision: https://reviews.llvm.org/D25858

llvm-svn: 286663

show more ...


# 44e875ad 07-Nov-2016 Kuba Brecka <kuba.brecka@gmail.com>

[tsan] Cast floating-point types correctly when instrumenting atomic accesses, LLVM part

Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. T

[tsan] Cast floating-point types correctly when instrumenting atomic accesses, LLVM part

Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. The TSan instrumentation pass however tries to emit inttoptr, which is incorrect, we should use a bitcast here. Anyway, IRBuilder already has a convenient helper function for this.

Differential Revision: https://reviews.llvm.org/D26266

llvm-svn: 286135

show more ...


# 117296c0 01-Oct-2016 Mehdi Amini <mehdi.amini@apple.com>

Use StringRef in Pass/PassManager APIs (NFC)

llvm-svn: 283004


Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2
# b03fd12c 17-Aug-2016 Justin Bogner <mail@justinbogner.com>

Replace "fallthrough" comments with LLVM_FALLTHROUGH

This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.

llvm

Replace "fallthrough" comments with LLVM_FALLTHROUGH

This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.

llvm-svn: 278902

show more ...


Revision tags: llvmorg-3.9.0-rc1
# 57faf2d2 19-Jul-2016 Vedant Kumar <vsk@apple.com>

[tsan] Don't instrument __llvm_gcov_global_state_pred or __llvm_gcda*

r274801 did not go far enough to allow gcov+tsan to cooperate. With this
commit it's possible to run the following code without

[tsan] Don't instrument __llvm_gcov_global_state_pred or __llvm_gcda*

r274801 did not go far enough to allow gcov+tsan to cooperate. With this
commit it's possible to run the following code without false positives:

std::thread T1(fib), T2(fib);
T1.join(); T2.join();

llvm-svn: 276015

show more ...


# 0fdffd37 07-Jul-2016 Vedant Kumar <vsk@apple.com>

[tsan] Try harder to not instrument gcov counters

GCOVProfiler::emitProfileArcs() can create many variables with names
starting with "__llvm_gcov_ctr", so llvm appends a numeric suffix to
most of th

[tsan] Try harder to not instrument gcov counters

GCOVProfiler::emitProfileArcs() can create many variables with names
starting with "__llvm_gcov_ctr", so llvm appends a numeric suffix to
most of them. Teach tsan about this.

llvm-svn: 274801

show more ...


# d7708773 24-Jun-2016 David Majnemer <david.majnemer@gmail.com>

Switch more loops to be range-based

This makes the code a little more concise, no functional change is
intended.

llvm-svn: 273644


# 644d9d3a 22-Jun-2016 Anna Zaks <ganna@apple.com>

[asan] Do not instrument pointers with address space attributes

Do not instrument pointers with address space attributes since we cannot track
them anyway. Instrumenting them results in false positi

[asan] Do not instrument pointers with address space attributes

Do not instrument pointers with address space attributes since we cannot track
them anyway. Instrumenting them results in false positives in ASan and a
compiler crash in TSan. (The compiler should not crash in any case, but that's
a different problem.)

llvm-svn: 273339

show more ...


# 0222adbc 20-Jun-2016 Vedant Kumar <vsk@apple.com>

[tsan] Do not instrument accesses to the gcov counters array

There is a known intended race here. This is a follow-up to r264805,
which disabled tsan instrumentation for updates to instrprof counter

[tsan] Do not instrument accesses to the gcov counters array

There is a known intended race here. This is a follow-up to r264805,
which disabled tsan instrumentation for updates to instrprof counters.
For more background on this please see the discussion in D18164.

llvm-svn: 273202

show more ...


# 3feda222 18-Jun-2016 Marcin Koscielnicki <koriakin@0x04.net>

[sanitizers] Disable target-specific lowering of string functions.

CodeGen has hooks that allow targets to emit specialized code instead
of calls to memcmp, memchr, strcpy, stpcpy, strcmp, strlen, s

[sanitizers] Disable target-specific lowering of string functions.

CodeGen has hooks that allow targets to emit specialized code instead
of calls to memcmp, memchr, strcpy, stpcpy, strcmp, strlen, strnlen.
When ASan/MSan/TSan/ESan is in use, this sidesteps its interceptors, resulting
in uninstrumented memory accesses. To avoid that, make these sanitizers
mark the calls as nobuiltin.

Differential Revision: http://reviews.llvm.org/D19781

llvm-svn: 273083

show more ...


Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1
# 4fb78518 07-Apr-2016 Benjamin Kramer <benny.kra@googlemail.com>

Make helper functions static. NFC.

llvm-svn: 265653


# 800f87a8 06-Apr-2016 JF Bastien <jfb@google.com>

NFC: make AtomicOrdering an enum class

Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 b

NFC: make AtomicOrdering an enum class

Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 barring a small question that's still open.

The code currently plays fast and loose with the AtomicOrdering
enum. Using an enum class is one step towards tightening things. I later
also want to tighten related enums, such as clang's
AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI'
enum).

This change touches a few lines of code which can be improved later, I'd
like to keep it as NFC for now as it's already quite complex. I have
related changes for clang.

As a follow-up I'll add:
bool operator<(AtomicOrdering, AtomicOrdering) = delete;
bool operator>(AtomicOrdering, AtomicOrdering) = delete;
bool operator<=(AtomicOrdering, AtomicOrdering) = delete;
bool operator>=(AtomicOrdering, AtomicOrdering) = delete;
This is separate so that clang and LLVM changes don't need to be in sync.

Reviewers: jyknight, reames

Subscribers: jyknight, llvm-commits

Differential Revision: http://reviews.llvm.org/D18775

llvm-svn: 265602

show more ...


# 1a470b6f 29-Mar-2016 Anna Zaks <ganna@apple.com>

[tsan] Do not instrument reads/writes to instruction profile counters.

We have known races on profile counters, which can be reproduced by enabling
-fsanitize=thread and -fprofile-instr-generate sim

[tsan] Do not instrument reads/writes to instruction profile counters.

We have known races on profile counters, which can be reproduced by enabling
-fsanitize=thread and -fprofile-instr-generate simultaneously on a
multi-threaded program. This patch avoids reporting those races by not
instrumenting the reads and writes coming from the instruction profiler.

llvm-svn: 264805

show more ...


# c1efa64c 07-Mar-2016 Anna Zaks <ganna@apple.com>

[tsan] Add support for pointer typed atomic stores, loads, and cmpxchg

TSan instrumentation functions for atomic stores, loads, and cmpxchg work on
integer value types. This patch adds casts before

[tsan] Add support for pointer typed atomic stores, loads, and cmpxchg

TSan instrumentation functions for atomic stores, loads, and cmpxchg work on
integer value types. This patch adds casts before calling TSan instrumentation
functions in cases where the value is a pointer.

Differential Revision: http://reviews.llvm.org/D17833

llvm-svn: 262876

show more ...


Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3
# dfb655fe 15-Aug-2015 Yaron Keren <yaron.keren@gmail.com>

Try to appease VS 2015 warnings from http://reviews.llvm.org/D11890
ByteSize and BitSize should not be size_t but unsigned, considering

1) They are at most 2^16 and 2^19, respectively.
2) BitSize is

Try to appease VS 2015 warnings from http://reviews.llvm.org/D11890
ByteSize and BitSize should not be size_t but unsigned, considering

1) They are at most 2^16 and 2^19, respectively.
2) BitSize is an argument to Type::getIntNTy which takes unsigned.

Also, use the correct utostr instead itostr and cache the string result.

Thanks to James Touton for reporting this!

llvm-svn: 245167

show more ...


Revision tags: studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1
# ff6409d0 18-May-2015 David Blaikie <dblaikie@gmail.com>

Simplify IRBuilder::CreateCall* by using ArrayRef+initializer_list/braced init only

llvm-svn: 237624


Revision tags: llvmorg-3.6.1, llvmorg-3.6.1-rc1
# 2d4ae9f0 07-May-2015 Ismail Pazarbasi <ismail.pazarbasi@gmail.com>

TSan: Use `createSanitizerCtor` to create ctor, and call `__tsan_init`

Reviewers: kcc, dvyukov

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8779

llvm-svn: 236778


# 198d6d53 06-Apr-2015 Ismail Pazarbasi <ismail.pazarbasi@gmail.com>

Move `checkInterfaceFunction` to ModuleUtils

Summary:
Instead of making a local copy of `checkInterfaceFunction` for each
sanitizer, move the function in a common place.

Reviewers: kcc, samsonov

S

Move `checkInterfaceFunction` to ModuleUtils

Summary:
Instead of making a local copy of `checkInterfaceFunction` for each
sanitizer, move the function in a common place.

Reviewers: kcc, samsonov

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8775

llvm-svn: 234220

show more ...


1234567