| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:
1) Function is explicitly blacklisted by its mangled name.
This part is not changed.
2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.
After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.
After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.
I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).
llvm-svn: 219997
|
|
They cannot be written to, so marking them const makes sense and may improve
optimisation.
As a side-effect, SectionInfos has to be moved from Sema to ASTContext.
It also fixes this problem, that occurs when compiling ATL:
warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes
The ATL headers are putting variables in a special section that's marked
read-only. However, Clang currently can't model that read-onlyness in the IR.
But, by making the variables const, the section does become read-only, and
the linker warning is avoided.
Differential Revision: http://reviews.llvm.org/D5812
llvm-svn: 219960
|
|
CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.
Even if the definition was already emitted, it would never mark the
alias as thread_local.
This fixes PR21288.
llvm-svn: 219859
|
|
Soon we'll need to have access to blacklist before the CodeGen
phase (see http://reviews.llvm.org/D5687), so parse and construct
the blacklist earlier.
llvm-svn: 219857
|
|
After http://reviews.llvm.org/D5687 is submitted, we will need
SanitizerBlacklist before the CodeGen phase, so make it a LangOpt
(as it will actually affect ABI / class layout).
llvm-svn: 219842
|
|
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.
Differential Revision: http://reviews.llvm.org/D5365
llvm-svn: 219393
|
|
llvm-svn: 219258
|
|
This patch makes sure that the dllexport attribute is transferred to the alias when such alias is created. It only affects the Itanium ABI because for the MSVC ABI a workaround is in place to not generate aliases of dllexport ctors/dtors.
A new CodeGenModule function is provided, CodeGenModule::setAliasAttributes, to factor the code for transferring attributes to aliases.
llvm-svn: 218159
|
|
There are situations when clang knows that the C1 and C2 constructors
or the D1 and D2 destructors are identical. We already optimize some
of these cases, but cannot optimize it when the GlobalValue is
weak_odr.
The problem with weak_odr is that an old TU seeing the same code will
have a C1 and a C2 comdat with the corresponding symbols. We cannot
suddenly start putting the C2 symbol in the C1 comdat as we cannot
guarantee that the linker will not pick a .o with only C1 in it.
The solution implemented by GCC is to expand the ABI to have a comdat
whose name uses a C5/D5 suffix and always has both symbols. That is
what this patch implements.
llvm-svn: 217874
|
|
A followup patch will address the code duplication.
llvm-svn: 217807
|
|
emitCXXDestructor static helpers.
A next patch will make it a helper in CGCXXABI.
llvm-svn: 217804
|
|
llvm-svn: 217386
|
|
llvm-svn: 217384
|
|
declaration (PR20792)
For the following code:
__declspec(dllimport) int f(int x);
int user(int x) {
return f(x);
}
int f(int x) { return 1; }
Clang will drop the dllimport attribute in the AST, but CodeGen would have
already put it on the LLVM::Function, and that would never get updated.
(The same thing happens for global variables.)
This makes Clang check dropped DLL attribute case each time the LLVM object
is referenced.
This isn't perfect, because we will still get it wrong if the function is
never referenced by codegen after the attribute is dropped, but this handles
the common cases and makes us not fail in the verifier.
llvm-svn: 216699
|
|
Differential Revision: http://reviews.llvm.org/D4799
llvm-svn: 215258
|
|
int __declspec(align(16)) foo; is a tentative definition but the storage
for that variable should not have CommonLinkage.
llvm-svn: 214828
|
|
This patch adds the '-fcoverage-mapping' option which
allows clang to generate the coverage mapping information
that can be used to provide code coverage analysis using
the execution counts obtained from the instrumentation
based profiling (-fprofile-instr-generate).
llvm-svn: 214752
|
|
involved.
llvm-svn: 214606
|
|
llvm-svn: 214579
|
|
It is responsible for generating metadata consumed by sanitizer instrumentation
passes in the backend. Move several methods from CodeGenModule to SanitizerMetadata.
For now the class is stateless, but soon it won't be the case.
Instead of creating globals providing source-level information to ASan, we will create
metadata nodes/strings which will be turned into actual global variables in the
backend (if needed).
No functionality change.
llvm-svn: 214564
|
|
Original message:
Fix iterator invalidation issues that are breaking my modules buildbot's
bootstrap.
llvm-svn: 214555
|
|
llvm-svn: 214549
|
|
bootstrap.
llvm-svn: 214547
|
|
they're somehow missing a body. Looks like this was left behind when the loop
was generalized, and it's not been problematic before because without modules,
a used, implicit special member function declaration must be a definition.
This was resulting in us trying to emit a constructor declaration rather than
a definition, and producing a constructor missing its member initializers.
llvm-svn: 214473
|
|
lengths! In passing, simplify string literal deduplication by relying on LLVM
to deduplicate the underlying constant values.
llvm-svn: 214222
|
|
Summary:
This change adds description of globals created by UBSan
instrumentation (UBSan handlers, type descriptors, filenames) to
llvm.asan.globals metadata, effectively "blacklisting" them. This can
dramatically decrease the data section in binaries built with UBSan+ASan,
as UBSan tends to create a lot of handlers, and ASan instrumentation
increases the global size to at least 64 bytes.
Test Plan: clang regression test suite
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, byoungyoung, kcc
Differential Revision: http://reviews.llvm.org/D4575
llvm-svn: 213392
|
|
members (PR20140)
This makes us emit dllexported in-class initialized static data members (which
are treated as definitions in MSVC), even when they're not referenced.
It also makes their special linkage reflected in the GVA linkage instead of
getting massaged in CodeGen.
Differential Revision: http://reviews.llvm.org/D4563
llvm-svn: 213304
|
|
error reports.
Currently ASan instrumentation pass creates a string with global name
for each instrumented global (to include global names in the error report). Global
name is already mangled at this point, and we may not be able to demangle it
at runtime (e.g. there is no __cxa_demangle on Android).
Instead, create a string with fully qualified global name in Clang, and pass it
to ASan instrumentation pass in llvm.asan.globals metadata. If there is no metadata
for some global, ASan will use the original algorithm.
This fixes https://code.google.com/p/address-sanitizer/issues/detail?id=264.
llvm-svn: 212872
|
|
This would allow to call addCompilerUsedGlobal on some
Clang-generated globals.
llvm-svn: 212767
|
|
Turn llvm::SpecialCaseList into a simple class that parses text files in
a specified format and knows nothing about LLVM IR. Move this class into
LLVMSupport library. Implement two users of this class:
* DFSanABIList in DFSan instrumentation pass.
* SanitizerBlacklist in Clang CodeGen library.
The latter will be modified to use actual source-level information from frontend
(source file names) instead of unstable LLVM IR things (LLVM Module identifier).
Remove dependency edge from ClangCodeGen/ClangDriver to LLVMTransformUtils.
No functionality change.
llvm-svn: 212643
|
|
Get rid of cached CodeGenModule::SanOpts, which was used to turn off
sanitizer codegen options if current LLVM Module is blacklisted, and use
plain LangOpts.Sanitize instead.
1) Some codegen decisions (turning TBAA or writable strings on/off)
shouldn't depend on the contents of blacklist.
2) llvm.asan.globals should *always* be created, even if the module
is blacklisted - soon Clang's CodeGen where we read sanitizer
blacklist files, so we should properly report which globals are
blacklisted to the backend.
llvm-svn: 212499
|
|
Let's not expose ABI specific minutia inside of CodeGenModule and Type.
Instead, let's abstract it through CXXABI.
This gets rid of:
CodeGenModule::getCompleteObjectLocator,
CodeGenModule::EmitFundamentalTypeDescriptor{s,},
CodeGenModule::getMSTypeDescriptor,
CodeGenModule::getMSCompleteObjectLocator,
CGCXXABI::shouldRTTIBeUnique,
CGCXXABI::classifyRTTIUniqueness.
CGRTTI was *almost* entirely centered around providing Itanium-style
RTTI information. Instead of providing interfaces that only it
consumes, move it to the ItaniumCXXABI implementation file. This allows
it to have access to Itanium-specific implementation details without
providing useless expansion points for the Microsoft ABI side.
Differential Revision: http://reviews.llvm.org/D4261
llvm-svn: 212435
|
|
Summary:
Because a global created by GetOrCreateLLVMGlobal() is not finalised until later viz:
extern char a[];
char f(){ return a[5];}
char a[10];
Change MangledDeclNames to use a MapVector rather than a DenseMap so that the
Metadata is output in order of original declaration, so to make deterministic
and improve human readablity.
Differential Revision: http://reviews.llvm.org/D4176
llvm-svn: 212263
|
|
Differential Revision: http://reviews.llvm.org/D4176
llvm-svn: 212262
|
|
See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the
original feature request.
Introduce llvm.asan.globals metadata, which Clang (or any other frontend)
may use to report extra information about global variables to ASan
instrumentation pass in the backend. This metadata replaces
llvm.asan.dynamically_initialized_globals that was used to detect init-order
bugs. llvm.asan.globals contains the following data for each global:
1) source location (file/line/column info);
2) whether it is dynamically initialized;
3) whether it is blacklisted (shouldn't be instrumented).
Source location data is then emitted in the binary and can be picked up
by ASan runtime in case it needs to print error report involving some global.
For example:
0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40
These source locations are printed even if the binary doesn't have any
debug info.
This is an ABI-breaking change. ASan initialization is renamed to
__asan_init_v4(). Pre-built libraries compiled with older Clang will not work
with the fresh runtime.
llvm-svn: 212188
|
|
Improve the warning when building with -fprofile-instr-use and a file
appears not to have been profiled at all. This keys on whether a
function is defined in the main file or not to avoid false negatives
when one includes a header with functions that have been profiled.
llvm-svn: 211760
|
|
llvm-svn: 211528
|
|
Add module flags metadata to record the settings for enum and wchar width,
to allow correct ARM build attribute generation
llvm-svn: 211354
|
|
llvm-svn: 210780
|
|
The backing store of thread local variables is internal for OS X and all
accesses must go through the thread wrapper.
However, individual TUs may have inlined through the thread wrapper.
To fix this, give the thread wrapper functions WeakAnyLinkage. This
prevents them from getting inlined into call-sites.
This fixes PR19989.
llvm-svn: 210632
|
|
llvm-svn: 210448
|
|
Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.
This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.
An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.
llvm-svn: 210293
|
|
llvm-svn: 210214
|
|
GetAddrOfConstantStringFromLiteral.
Share mode code between these functions and re-structure them in a way
which shows how similar they actually are. The latter function works well
with literals of multi-byte chars and does a GlobalVariable name mangling
(if global strings are non-writable).
No functionality change.
llvm-svn: 210212
|
|
llvm-svn: 210206
|
|
Aliases in llvm now hold an arbitrary expression.
llvm-svn: 210063
|
|
The only remaining user didn't actually use the non-dynamic storage facility
this class provides.
The std::string is transitional and likely to be StringRefized shortly.
llvm-svn: 210058
|
|
llvm-svn: 209826
|
|
Clang knows about the sanitizer blacklist and it makes no sense to
add global to the list of llvm.asan.dynamically_initialized_globals if it
will be blacklisted in the instrumentation pass anyway. Instead, we should
do as much blacklisting as possible (if not all) in the frontend.
llvm-svn: 209789
|
|
MSVC doesn't export these functions, so trying to import them doesnt' work.
Also, don't let any dll attributes on the CXXDestructorDecl influence the
thunk's linkage -- they should always be linkonce_odr.
This takes care of the FIXME's for this in Nico's tests.
Differential Revision: http://reviews.llvm.org/D3930
llvm-svn: 209706
|
