Age | Commit message (Collapse) | Author |
|
equal strings are merged by the linker. Observed up to 1% binary size reduction. Thanks to Anton Korobeynikov for the suggestion
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177264 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177254 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177250 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177063 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176075 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175617 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
long double will require a more general solution
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175442 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
https://code.google.com/p/address-sanitizer/issues/detail?id=151
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175266 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175033 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
may get mapped at 0x100000000+ and thus may interleave with the shadow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174964 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174957 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the redzone)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173335 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 for details
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173258 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
includes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172806 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the values of shadow scale and offset to the runtime
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172709 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
passes. Add test for non-default mapping scale and offset. No functionality change
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171253 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it describes one of 'interesting' allocas. Assume that allocas can go through casts and phi-nodes before apperaring as llvm.lifetime arguments
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171153 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
consistency
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171061 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171060 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
single attribute in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170502 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169984 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
does not change the current behavior)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169216 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
emit calls into runtime library that poison memory for local variables when their lifetime is over and unpoison memory when their lifetime begins.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169200 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169143 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168995 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the module is blacklisted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168913 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168910 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to doInitialization. This is required to allow the upcoming changes in PassManager behavior
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168864 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the callee
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168861 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLVM part. This requires a clang part which will follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
AddressSanitizerCreateGlobalRedzonesPass::ID. [-Wunused-variable]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168499 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
AddressSanitizer class into a separate class. The intent is to make it a separate ModulePass in the following commmits
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168484 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
globals generated by asan
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168368 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
linkage in -asan-initialization-order mode
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168367 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instrumented even in -asan-initialization-order mode. This time with a test
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
interface function is being redefined. Before this fix asan asserts)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167529 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167295 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
binary size a bit)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167230 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167222 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166278 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This became important after the recent move from ModulePass to FunctionPass because no cleanup is happening after asan pass any more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166267 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166102 91177308-0d34-0410-b5e6-96231b3b80d8
|