| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists. There is nothing of any import
worth testing until such time as little-endian code generation is
implemented. In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.
llvm-svn: 187179
|
|
|
|
| |
llvm-svn: 186371
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A special case list can now specify categories for specific globals,
which can be used to instruct an instrumentation pass to treat certain
functions or global variables in a specific way, such as by omitting
certain aspects of instrumentation while keeping others, or informing
the instrumentation pass that a specific uninstrumentable function
has certain semantics, thus allowing the pass to instrument callers
according to those semantics.
For example, AddressSanitizer now uses the "init" category instead of
global-init prefixes for globals whose initializers should not be
instrumented, but which in all other respects should be instrumented.
The motivating use case is DataFlowSanitizer, which will have a
number of different categories for uninstrumentable functions, such
as "functional" which specifies that a function has pure functional
semantics, or "discard" which indicates that a function's return
value should not be labelled.
Differential Revision: http://llvm-reviews.chandlerc.com/D1092
llvm-svn: 185978
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D1089
llvm-svn: 185975
|
|
|
|
|
|
| |
more than the redzone size
llvm-svn: 184928
|
|
|
|
| |
llvm-svn: 184927
|
|
|
|
| |
llvm-svn: 183104
|
|
|
|
| |
llvm-svn: 182680
|
|
|
|
| |
llvm-svn: 182315
|
|
|
|
|
|
| |
pointer to private string with module name. This string serves as a unique module ID in ASan runtime. LLVM part
llvm-svn: 178013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before: the function name was stored by the compiler as a constant string
and the run-time was printing it.
Now: the PC is stored instead and the run-time prints the full symbolized frame.
This adds a couple of instructions into every function with non-empty stack frame,
but also reduces the binary size because we store less strings (I saw 2% size reduction).
This change bumps the asan ABI version to v3.
llvm part.
Example of report (now):
==31711==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffa77cf1c5 at pc 0x41feb0 bp 0x7fffa77cefb0 sp 0x7fffa77cefa8
READ of size 1 at 0x7fffa77cf1c5 thread T0
#0 0x41feaf in Frame0(int, char*, char*, char*) stack-oob-frames.cc:20
#1 0x41f7ff in Frame1(int, char*, char*) stack-oob-frames.cc:24
#2 0x41f477 in Frame2(int, char*) stack-oob-frames.cc:28
#3 0x41f194 in Frame3(int) stack-oob-frames.cc:32
#4 0x41eee0 in main stack-oob-frames.cc:38
#5 0x7f0c5566f76c (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#6 0x41eb1c (/usr/local/google/kcc/llvm_cmake/a.out+0x41eb1c)
Address 0x7fffa77cf1c5 is located in stack of thread T0 at offset 293 in frame
#0 0x41f87f in Frame0(int, char*, char*, char*) stack-oob-frames.cc:12 <<<<<<<<<<<<<< this is new
This frame has 6 object(s):
[32, 36) 'frame.addr'
[96, 104) 'a.addr'
[160, 168) 'b.addr'
[224, 232) 'c.addr'
[288, 292) 's'
[352, 360) 'd'
llvm-svn: 177724
|
|
|
|
|
|
| |
equal strings are merged by the linker. Observed up to 1% binary size reduction. Thanks to Anton Korobeynikov for the suggestion
llvm-svn: 177264
|
|
|
|
|
|
| |
module name in a separate field, thus not duplicating this information if every description. This decreases the binary size (observed up to 3%). https://code.google.com/p/address-sanitizer/issues/detail?id=168 . This changes the asan API version. llvm-part
llvm-svn: 177254
|
|
|
|
|
|
| |
saves a bit of compile time and reduces the number of redundant global strings generated by asan (https://code.google.com/p/address-sanitizer/issues/detail?id=167)
llvm-svn: 177250
|
|
|
|
| |
llvm-svn: 177063
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
llvm-svn: 176075
|
|
|
|
| |
llvm-svn: 175617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes asan instrument memory accesses with unusual sizes (e.g. 5 bytes or 10 bytes), e.g. long double or
packed structures.
Instrumentation is done with two 1-byte checks
(first and last bytes) and if the error is found
__asan_report_load_n(addr, real_size) or
__asan_report_store_n(addr, real_size)
is called.
Also, call these two new functions in memset/memcpy
instrumentation.
asan-rt part will follow.
llvm-svn: 175507
|
|
|
|
|
|
| |
long double will require a more general solution
llvm-svn: 175442
|
|
|
|
|
|
| |
https://code.google.com/p/address-sanitizer/issues/detail?id=151
llvm-svn: 175266
|
|
|
|
| |
llvm-svn: 175033
|
|
|
|
|
|
| |
may get mapped at 0x100000000+ and thus may interleave with the shadow.
llvm-svn: 174964
|
|
|
|
|
|
| |
roughly 5% speedup. Since this is an ABI change, bump the asan ABI version by renaming __asan_init to __asan_init_v1. llvm part, compiler-rt part will follow
llvm-svn: 174957
|
|
|
|
|
|
|
|
|
|
| |
This flag makes asan use a small (<2G) offset for 64-bit asan shadow mapping.
On x86_64 this saves us a register, thus achieving ~2/3 of the
zero-base-offset's benefits in both performance and code size.
Thanks Jakub Jelinek for the idea.
llvm-svn: 174886
|
|
|
|
| |
llvm-svn: 173338
|
|
|
|
|
|
| |
the redzone)
llvm-svn: 173335
|
|
|
|
|
|
| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 for details
llvm-svn: 173258
|
|
|
|
|
|
| |
includes.
llvm-svn: 172891
|
|
|
|
| |
llvm-svn: 172806
|
|
|
|
|
|
| |
the values of shadow scale and offset to the runtime
llvm-svn: 172709
|
|
|
|
|
|
| |
passes. Add test for non-default mapping scale and offset. No functionality change
llvm-svn: 172610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
|
|
|
|
|
|
|
|
|
| |
utils/sort_includes.py script.
Most of these are updating the new R600 target and fixing up a few
regressions that have creeped in since the last time I sorted the
includes.
llvm-svn: 171362
|
|
|
|
|
|
|
|
|
| |
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
llvm-svn: 171253
|
|
|
|
|
|
| |
it describes one of 'interesting' allocas. Assume that allocas can go through casts and phi-nodes before apperaring as llvm.lifetime arguments
llvm-svn: 171153
|
|
|
|
|
|
| |
consistency
llvm-svn: 171061
|
|
|
|
| |
llvm-svn: 171060
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
|
|
|
|
|
|
|
|
|
|
|
| |
When ASan replaces <alloca instruction> with
<offset into a common large alloca>, it should also patch
llvm.dbg.declare calls and replace debug info descriptors to mark
that we've replaced alloca with a value that stores an address
of the user variable, not the user variable itself.
See PR11818 for more context.
llvm-svn: 169984
|
|
|
|
|
|
| |
does not change the current behavior)
llvm-svn: 169216
|
|
|
|
|
|
| |
emit calls into runtime library that poison memory for local variables when their lifetime is over and unpoison memory when their lifetime begins.
llvm-svn: 169200
|
|
|
|
| |
llvm-svn: 169143
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
| |
llvm-svn: 168995
|
|
|
|
|
|
| |
the module is blacklisted.
llvm-svn: 168913
|
|
|
|
| |
llvm-svn: 168910
|
|
|
|
|
|
| |
to doInitialization. This is required to allow the upcoming changes in PassManager behavior
llvm-svn: 168864
|
|
|
|
|
|
| |
the callee
llvm-svn: 168861
|
|
|
|
|
|
| |
LLVM part. This requires a clang part which will follow.
llvm-svn: 168781
|
|
|
|
|
|
| |
AddressSanitizerCreateGlobalRedzonesPass::ID. [-Wunused-variable]
llvm-svn: 168499
|