| 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
|
|
|
|
|
|
|
| |
uses that wanted it. Also change the interface for createCompileUnit
to compensate. Fix comments that refer to TheCU as well.
llvm-svn: 186637
|
|
|
|
|
|
| |
This reverts commit r186599 as I didn't want to commit this yet.
llvm-svn: 186601
|
|
|
|
|
|
|
| |
uses that wanted it. Also change the interface for createCompileUnit
to compensate. Fix comments that refer to TheCU as well.
llvm-svn: 186599
|
|
|
|
|
|
|
|
| |
of operator bool change.
Also convert a variable in DebugIR.
llvm-svn: 186544
|
|
|
|
| |
llvm-svn: 186485
|
|
|
|
| |
llvm-svn: 186484
|
|
|
|
|
|
|
| |
This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).
llvm-svn: 186447
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 185719
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185606
|
|
|
|
|
|
|
| |
This changes behavior of -msan-poison-stack=0 flag from not poisoning stack
allocations to actively unpoisoning them.
llvm-svn: 185538
|
|
|
|
| |
llvm-svn: 185456
|
|
|
|
|
|
|
| |
No functionality change. It should suffice to check the type of a debug info
metadata, instead of calling Verify.
llvm-svn: 185383
|
|
|
|
|
|
| |
- should unbreak Windows builds
llvm-svn: 185198
|
|
|
|
|
|
| |
- missed svn add...
llvm-svn: 185194
|
|
|
|
|
|
|
|
| |
- Build debug metadata for 'bare' Modules using DIBuilder
- DebugIR can be constructed to generate an IR file (to be seen by a debugger)
or not in cases where the user already has an IR file on disk.
llvm-svn: 185193
|
|
|
|
|
|
|
|
|
|
|
| |
No functionality change.
It should suffice to check the type of a debug info metadata, instead of
calling Verify. For cases where we know the type of a DI metadata, use
assert.
Also update testing cases to make them conform to the format of DI classes.
llvm-svn: 185135
|
|
|
|
|
|
| |
This reverts commit r185020
llvm-svn: 185032
|
|
|
|
|
|
|
|
| |
No functionality change.
It should suffice to check the type of a debug info metadata, instead of
calling Verify.
llvm-svn: 185020
|
|
|
|
|
|
| |
more than the redzone size
llvm-svn: 184928
|
|
|
|
| |
llvm-svn: 184927
|
|
|
|
| |
llvm-svn: 184174
|
|
|
|
|
|
|
| |
Most clients have already been moved from Path V1 to V2. The ones using V1
now include PathV1.h explicitly.
llvm-svn: 183801
|
|
|
|
| |
llvm-svn: 183104
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, each module defined a weak_odr global __msan_track_origins
with a value of 1 if origin tracking is enabled, 0 if disabled. If there are
modules with different values, any of them may win. If 0 wins, and there is at
least one module with 1, the program will most likely crash.
With this change, __msan_track_origins is only emitted if origin tracking is
on. Then runtime library detects if there is at least one module with origin
tracking, and enables runtime support for it.
llvm-svn: 182997
|
|
|
|
| |
llvm-svn: 182771
|
|
|
|
| |
llvm-svn: 182680
|
|
|
|
|
|
|
|
|
|
|
| |
- move AsmWriter.h from public headers into lib
- marked all AssemblyWriter functions as non-virtual; no need to override them
- DebugIR now "plugs into" AssemblyWriter with an AssemblyAnnotationWriter helper
- exposed flags to control hiding of a) debug metadata b) debug intrinsic calls
C/R: Paul Redmond
llvm-svn: 182617
|
|
|
|
|
|
|
| |
This stuff is used on platforms where MSan does not have a proper VarArg
implementation (anything other than x86_64 at the moment).
llvm-svn: 182375
|
|
|
|
| |
llvm-svn: 182315
|
|
|
|
|
|
| |
They are always defined in the main executable.
llvm-svn: 181994
|
|
|
|
| |
llvm-svn: 181551
|
|
|
|
|
|
|
|
|
|
|
| |
- requires existing debug information to be present
- fixes up file name and line number information in metadata
- emits a "<orig_filename>-debug.ll" succinct IR file (without !dbg metadata
or debug intrinsics) that can be read by a debugger
- initialize pass in opt tool to enable the "-debug-ir" flag
- lit tests to follow
llvm-svn: 181467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
llvm-svn: 180881
|
|
|
|
|
|
|
| |
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.
llvm-svn: 180063
|
|
|
|
| |
llvm-svn: 179280
|
|
|
|
|
|
| |
Go ahead and use the full path for both the .gcno and .gcda files.
llvm-svn: 178302
|
|
|
|
| |
llvm-svn: 178230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we compile a single source program, the `.gcda' file will be generated where
the program was executed. This isn't desirable, because that place may be at an
unpredictable place (the program could call `chdir' for instance).
Instead, we will output the `.gcda' file in the same place we output the `.gcno'
file. I.e., the directory where the executable was generated. This matches GCC's
behavior.
<rdar://problem/13061072> & PR11809
llvm-svn: 178084
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This is required to determine ctor/dtor vs virtual call races.
http://llvm-reviews.chandlerc.com/D566
llvm-svn: 177717
|
|
|
|
| |
llvm-svn: 177630
|
|
|
|
|
|
|
|
|
|
|
| |
Use the new `llvm_gcov_init' function to register the writeout and flush
functions. The initialization function will also call `atexit' for some cleanups
and final writout calls. But it does this only once. This is better than
checking for the `main' function, because in a library that function may not
exist.
<rdar://problem/12439551>
llvm-svn: 177579
|
|
|
|
|
|
|
|
|
| |
We don't want to write out >1000 files at the same time. That could make things
prohibitively expensive. Instead, register the "writeout" function so that it's
emitted serially.
<rdar://problem/12439551>
llvm-svn: 177437
|
|
|
|
|
|
| |
that we'll prefer to emit the mangled C++ name (pending a clang change).
llvm-svn: 177371
|
|
|
|
|
|
|
|
|
|
| |
For each compile unit, we want to register a function that will flush that
compile unit. Otherwise, __gcov_flush() would only flush the counters within the
current compile unit, and not any outside of it.
PR15191 & <rdar://problem/13167507>
llvm-svn: 177340
|