| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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
|
|
|
|
|
|
| |
AddressSanitizer class into a separate class. The intent is to make it a separate ModulePass in the following commmits
llvm-svn: 168484
|
|
|
|
|
|
| |
globals generated by asan
llvm-svn: 168368
|
|
|
|
|
|
| |
linkage in -asan-initialization-order mode
llvm-svn: 168367
|
|
|
|
|
|
| |
instrumented even in -asan-initialization-order mode. This time with a test
llvm-svn: 168366
|
|
|
|
|
|
| |
interface function is being redefined. Before this fix asan asserts)
llvm-svn: 167529
|
|
|
|
| |
llvm-svn: 167295
|
|
|
|
|
|
| |
binary size a bit)
llvm-svn: 167230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address space basis.
Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.
However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.
In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.
In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.
This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.
llvm-svn: 167222
|
|
|
|
| |
llvm-svn: 166278
|
|
|
|
|
|
| |
This became important after the recent move from ModulePass to FunctionPass because no cleanup is happening after asan pass any more.
llvm-svn: 166267
|
|
|
|
| |
llvm-svn: 166102
|
|
|
|
|
|
| |
different pointer sizes on a per address space basis.
llvm-svn: 165941
|
|
|
|
|
|
| |
This will simplify chaining other FunctionPasses with asan. Also some minor cleanup
llvm-svn: 165936
|
|
|
|
| |
llvm-svn: 165747
|
|
|
|
|
|
| |
per address space pointer sizes to be optimized correctly.
llvm-svn: 165726
|
|
|
|
|
|
|
| |
We use the enums to query whether an Attributes object has that attribute. The
opaque layer is responsible for knowing where that specific attribute is stored.
llvm-svn: 165488
|