| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 219355
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change modifies fatal signal handler used in LLVM tools.
Now it attempts to find llvm-symbolizer binary and communicates
with it in order to turn instruction addresses into
function/file/line info entries. This should significantly improve
stack traces readability in Debug builds.
This feature only works on selected platforms (including Darwin
and Linux). If the symbolization fails for some reason, signal
handler will fallback to the original behavior.
Reviewed in http://reviews.llvm.org/D5610
llvm-svn: 219354
|
| |
|
|
|
|
|
|
| |
We won't link in pthreads if we weren't built with LLVM_ENABLE_THREADS
which means we won't get access to pthread_sigmask. Use sigprocmask
instead.
llvm-svn: 219288
|
| |
|
|
|
|
|
|
|
|
| |
mach-o supports "fat" files which are a header/table-of-contents followed by a
concatenation of mach-o files built for different architectures. Currently,
MemoryBuffer has no easy way to map a subrange (slice) of a file which lld
will need to select a mach-o slice of a fat file. The new function provides
an easy way to map a slice of a file into a MemoryBuffer. Test case included.
llvm-svn: 219260
|
| |
|
|
|
|
|
| |
getOpenFileSlice gets passed the map size, so it makes no sense to say that
the size is volatile. The code will not even compute the size.
llvm-svn: 219226
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On this file we had a mix of
* Twine
* const char *
* StringRef
The two that make sense are
* const Twine & (caller convenience)
* consc char * (that is what will eventually be passed to open.
Given that sys::fs::openFileForRead takes a "const Twine &", I picked that.
llvm-svn: 219224
|
| |
|
|
| |
llvm-svn: 219190
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most Unix-like operating systems guarantee that the file descriptor is
closed after a call to close(2), even if close comes back with EINTR.
For these systems, calling close _again_ will either do nothing or close
some other file descriptor open(2)'d by another thread. (Linux)
However, some operating systems do not have this behavior. They require
at least another call to close(2) before guaranteeing that the
descriptor is closed. (HP-UX)
And some operating systems have an unpredictable blend of the two
behaviors! (xnu)
Avoid this disaster by blocking all signals before we call close(2).
This ensures that a signal will not be delivered to the thread and
close(2) will not give us back EINTR. We restore the signal mask once
the operation is done.
N.B. This isn't a problem on Windows, it doesn't have a notion of EINTR
because signals always get delivered to dedicated signal handling
threads.
llvm-svn: 219189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's possible to start a program with one (or all) of the standard file
descriptors closed. Subsequent open system calls will give the program
a low-numbered file descriptor.
This is problematic because we may believe we are writing to standard
out instead of a file.
Introduce Process::FixupStandardFileDescriptors, a helper function to
remap standard file descriptors to /dev/null if they were closed before
the program started.
llvm-svn: 219170
|
| |
|
|
| |
llvm-svn: 219121
|
| |
|
|
|
|
| |
constructor and destructor.
llvm-svn: 219028
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
argument of the llvm.dbg.declare/llvm.dbg.value intrinsics.
Previously, DIVariable was a variable-length field that has an optional
reference to a Metadata array consisting of a variable number of
complex address expressions. In the case of OpPiece expressions this is
wasting a lot of storage in IR, because when an aggregate type is, e.g.,
SROA'd into all of its n individual members, the IR will contain n copies
of the DIVariable, all alike, only differing in the complex address
reference at the end.
By making the complex address into an extra argument of the
dbg.value/dbg.declare intrinsics, all of the pieces can reference the
same variable and the complex address expressions can be uniqued across
the CU, too.
Down the road, this will allow us to move other flags, such as
"indirection" out of the DIVariable, too.
The new intrinsics look like this:
declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr)
declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr)
This patch adds a new LLVM-local tag to DIExpressions, so we can detect
and pretty-print DIExpression metadata nodes.
What this patch doesn't do:
This patch does not touch the "Indirect" field in DIVariable; but moving
that into the expression would be a natural next step.
http://reviews.llvm.org/D4919
rdar://problem/17994491
Thanks to dblaikie and dexonsmith for reviewing this patch!
Note: I accidentally committed a bogus older version of this patch previously.
llvm-svn: 218787
|
| |
|
|
|
|
| |
"Move the complex address expression out of DIVariable and into an extra"
llvm-svn: 218782
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
argument of the llvm.dbg.declare/llvm.dbg.value intrinsics.
Previously, DIVariable was a variable-length field that has an optional
reference to a Metadata array consisting of a variable number of
complex address expressions. In the case of OpPiece expressions this is
wasting a lot of storage in IR, because when an aggregate type is, e.g.,
SROA'd into all of its n individual members, the IR will contain n copies
of the DIVariable, all alike, only differing in the complex address
reference at the end.
By making the complex address into an extra argument of the
dbg.value/dbg.declare intrinsics, all of the pieces can reference the
same variable and the complex address expressions can be uniqued across
the CU, too.
Down the road, this will allow us to move other flags, such as
"indirection" out of the DIVariable, too.
The new intrinsics look like this:
declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr)
declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr)
This patch adds a new LLVM-local tag to DIExpressions, so we can detect
and pretty-print DIExpression metadata nodes.
What this patch doesn't do:
This patch does not touch the "Indirect" field in DIVariable; but moving
that into the expression would be a natural next step.
http://reviews.llvm.org/D4919
rdar://problem/17994491
Thanks to dblaikie and dexonsmith for reviewing this patch!
llvm-svn: 218778
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::huge_valf is defined in a header file, so it is initialized
multiple times in every compiled unit upon program startup.
With non-VC compilers huge_valf is set to a HUGE_VALF which the
compiler can probably optimize out.
With VC numeric_limits<float>::infinity() does not return a number
but a runtime structure member which therotically may change
between calls so the compiler does not optimize out the
initialization and it happens many times. It can be easily seen by
placing a breakpoint on the initialization line.
This patch moves llvm::huge_valf initialization to a source file
instead of the header.
llvm-svn: 218567
|
| |
|
|
| |
llvm-svn: 218547
|
| |
|
|
|
|
|
| |
Don't negate signed integer types in &raw_ostream::operator<<(const
FormattedNumber &FN).
llvm-svn: 218496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::format() is somewhat unsafe. The compiler does not check that integer
parameter size matches the %x or %d size and it does not complain when a
StringRef is passed for a %s. And correctly using a StringRef with format() is
ugly because you have to convert it to a std::string then call c_str().
The cases where llvm::format() is useful is controlling how numbers and
strings are printed, especially when you want fixed width output. This
patch adds some new formatting functions to raw_streams to format numbers
and StringRefs in a type safe manner. Some examples:
OS << format_hex(255, 6) => "0x00ff"
OS << format_hex(255, 4) => "0xff"
OS << format_decimal(0, 5) => " 0"
OS << format_decimal(255, 5) => " 255"
OS << right_justify(Str, 5) => " foo"
OS << left_justify(Str, 5) => "foo "
llvm-svn: 218463
|
| |
|
|
| |
llvm-svn: 218401
|
| |
|
|
| |
llvm-svn: 218374
|
| |
|
|
| |
llvm-svn: 218373
|
| |
|
|
| |
llvm-svn: 218371
|
| |
|
|
| |
llvm-svn: 218370
|
| |
|
|
|
|
| |
'extern "C" static' is not accepted by g++-4.7. Rather to tweak, I just removed 'extern "C"', since it doesn't affect the ABI.
llvm-svn: 218290
|
| |
|
|
|
|
| |
static destructor.
llvm-svn: 218283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comparing ModuleName to the file names listed will
always fail.
I wonder how this code ever worked and what its
purpose was. Why exclude the msvc runtime DLLs
but not exclude all Windows system DLLs?
Anyhow, it does not function as intended.
clang-formatted as well.
llvm-svn: 218276
|
| |
|
|
| |
llvm-svn: 218142
|
| |
|
|
|
|
|
|
| |
It isn't always useful to skip blank lines, as evidenced by the
somewhat awkward use of line_iterator in llvm-cov. This adds a knob to
control whether or not to skip blanks.
llvm-svn: 217960
|
| |
|
|
|
|
| |
The wrong value was returned and the unittest did not cover the stub dylib case.
llvm-svn: 217933
|
| |
|
|
|
|
|
|
|
| |
There's some other cleanup that could happen here, but this is at least
the mechanical transformation to unique_ptr.
Derived from a patch by Anton Yartsev.
llvm-svn: 217803
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
le64 is a generic little-endian 64-bit processor, mimicking le32.
Depends on D5318.
Test Plan: make check-all
Reviewers: dschuff
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5319
llvm-svn: 217697
|
| |
|
|
| |
llvm-svn: 217666
|
| |
|
|
|
|
|
| |
Use llvm::COFF::BigObjMagic insetad of the string literal.
Also checks the version number.
llvm-svn: 217633
|
| |
|
|
|
|
|
| |
identify_magic recognized a COFF bigobj as an import library file.
This patch fixes that.
llvm-svn: 217627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main difference is the removal of
std::error_code exists(const Twine &path, bool &result);
It was an horribly redundant interface since a file not existing is also a valid
error_code. Now we have an access function that returns just an error_code. This
is the only function that has to be implemented for Unix and Windows. The
functions can_write, exists and can_execute an now just wrappers.
One still has to be very careful using these function to avoid introducing
race conditions (Time of check to time of use).
llvm-svn: 217625
|
| |
|
|
| |
llvm-svn: 217597
|
| |
|
|
|
|
| |
Patch by Andrew Turner.
llvm-svn: 217454
|
| |
|
|
|
|
| |
dereference it. This is a speculative fix for a failure found on the valgrind buildbot triggered by a clang test.
llvm-svn: 217295
|
| |
|
|
|
|
|
|
| |
test case on UBSan bootstrap bot.
This fixes the last failure of "check-clang" in UBSan bootstrap bot.
llvm-svn: 217294
|
| |
|
|
|
|
|
|
| |
LanguageString()"
This commit was reverted in r217183, but is OK to go in again now that its dependency is commited (as of r217186).
llvm-svn: 217231
|
| |
|
|
| |
llvm-svn: 217230
|
| |
|
|
|
|
|
|
| |
Reviewed in:
http://reviews.llvm.org/D5115
llvm-svn: 217229
|
| |
|
|
|
|
|
|
|
|
| |
Reviewed By: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5187
llvm-svn: 217186
|
| |
|
|
|
|
|
|
| |
This reverts commit 93c7e6161e1adbd2c7ac81fa081823183035cb64.
This commit got approved first, but was dependant on another one going in (The one pretty printing attribute values). I'll reapply when the other one is in.
llvm-svn: 217183
|
| |
|
|
|
|
|
|
|
|
| |
Reviewed By: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5193
llvm-svn: 217182
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds to LLVMSupport the capability of writing files with
international characters encoded in the current system encoding. This
is relevant for Windows, where we can either use UTF16 or the current
code page (the legacy Windows international characters). On UNIX, the
file is always saved in UTF8.
This will be used in a patch for clang to thoroughly support response
files creation when calling other tools, addressing PR15171. On
Windows, to correctly support internationalization, we need the
ability to write response files both in UTF16 or the current code
page, depending on the tool we will call. GCC for mingw, for instance,
requires files to be encoded in the current code page. MSVC tools
requires files to be encoded in UTF16.
Patch by Rafael Auler!
llvm-svn: 217068
|
| |
|
|
|
|
|
|
| |
This is part of our larger effort to remove static initializers from LLVM libraries.
Reviewed by: chandlerc
llvm-svn: 217053
|
| |
|
|
| |
llvm-svn: 216996
|
| |
|
|
| |
llvm-svn: 216925
|
| |
|
|
| |
llvm-svn: 216921
|