Remove two unused variables (-Werror).

llvm-svn: 300777

[sanitizer-coverage] remove stale code

llvm-svn: 300769

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 ty

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.

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

llvm-svn: 299949

show more ...

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 ...

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 ...

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

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

llvm-svn: 299702

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 ...

[sancov] Don't instrument blocks with no insertion point

This prevents crashes when attempting to instrument functions containing
C++ try.

Sanitizer coverage will still fail at runtime when an exce

[sancov] Don't instrument blocks with no insertion point

This prevents crashes when attempting to instrument functions containing
C++ try.

Sanitizer coverage will still fail at runtime when an exception is
thrown through a sancov instrumented function, but that seems marginally
better than what we have now. The full solution is to color the blocks
in LLVM IR and only instrument blocks that have an unambiguous color,
using the appropriate token.

llvm-svn: 298662

show more ...

[sancov] using comdat only when it is enabled

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

llvm-svn: 294529

[sancov] specifying comdat for sancov constructors

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

llvm-svn: 294517

[sanitizer coverage] Fix Instrumentation to work on Windows.

On Windows, the symbols "___stop___sancov_guards" and "___start___sancov_guards"
are not defined automatically. So, we need to take a dif

[sanitizer coverage] Fix Instrumentation to work on Windows.

On Windows, the symbols "___stop___sancov_guards" and "___start___sancov_guards"
are not defined automatically. So, we need to take a different approach.
We define 3 sections:

Section ".SCOV$A" will only hold a variable ___start___sancov_guard.
Section ".SCOV$M" will hold the main data.
Section ".SCOV$Z" will only hold a variable ___stop___sancov_guards.

When linking, they will be merged sorted by the characters after the $, so we
can use the pointers of the variables ___[start|stop]___sancov_guard to know the
actual range of addresses of that section.

In this diff, I updated instrumentation to include all the guard arrays in
section ".SCOV$M".

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

llvm-svn: 293987

show more ...

SanitizerCoverage: Support sanitizer guard section on darwin

MachO's sections need a segment as well as a section name, and the
section start and end symbols are spelled differently than on ELF.

ll

SanitizerCoverage: Support sanitizer guard section on darwin

MachO's sections need a segment as well as a section name, and the
section start and end symbols are spelled differently than on ELF.

llvm-svn: 293733

show more ...

[sanitizer-coverage] emit __sanitizer_cov_trace_pc_guard w/o a preceding 'if' by default. Update the docs, also add deprecation notes around other parts of sanitizer coverage

llvm-svn: 292862

[sanitizer-coverage] sort the switch cases

llvm-svn: 290628

[sanitizer-coverage] use IRB.SetCurrentDebugLocation after IRB.SetInsertPoint

llvm-svn: 288568

[sancov] Name the global containing the main source file name

If the global name doesn't start with __sancov_gen, ASan will insert
unecessary red zones around it.

llvm-svn: 287117

[sanitizer-coverage] make sure asan does not instrument coverage guards (reported in https://github.com/google/oss-fuzz/issues/84)

llvm-svn: 287030

[sancov] Don't instrument MSVC CRT stdio config helpers

They get called before initialization, which is a problem for winasan.

Test coming in compiler-rt.

llvm-svn: 286615

[sanitizer-coverage] use private linkage for coverage guards, delete old commented-out code.

llvm-svn: 283924

Use StringRef in Pass/PassManager APIs (NFC)

llvm-svn: 283004

[sanitizer-coverage/libFuzzer] make the guards for trace-pc 32-bit; create one array of guards per function, instead of one guard per BB. reorganize the code so that trace-pc-guard does not create un

[sanitizer-coverage/libFuzzer] make the guards for trace-pc 32-bit; create one array of guards per function, instead of one guard per BB. reorganize the code so that trace-pc-guard does not create unneeded globals

llvm-svn: 282735

show more ...

[sanitizer-coverage] fix a bug in trace-gep

llvm-svn: 282467

[sanitizer-coverage] don't emit the CTOR function if nothing has been instrumented

llvm-svn: 282465

[sanitizer-coverage] add comdat to coverage guards if needed

llvm-svn: 281952

[libFuzzer] use 'if guard' instead of 'if guard >= 0' with trace-pc; change the guard type to intptr_t; use separate array for 8-bit counters

llvm-svn: 281845