to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This ports the profiling runtime on Fuchsia and enables the
instrumentation. Unlike on other platforms, Fuchsia doesn't use
files to dump the instrumentation data since on Fuchsia, filesystem
may not be accessible to the instrumented process. We instead use
the data sink to pass the profiling data to the system the same
sanitizer runtimes do.
Differential Revision: https://reviews.llvm.org/D47208
llvm-svn: 337881
Summary:
The write buffer contains signed chars, which means the shift operations caused values such as the arc tag value (0x01a10000) to be read incorrectly (0xffa10000).
This fixes a regression from https://reviews.llvm.org/D49132.
Reviewers: uweigand, davidxl
Reviewed By: uweigand
Subscribers: llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49161
llvm-svn: 336775
Two fixes required to handle big-endian systems:
- 64-bit counter values are stored in a mixed-endian format in the
gcov files: a 32-bit low-part followed by a 32-bit high part. Note that
this is already implemented correctly on the LLVM side, see
GCOVBuffer::readInt64.
- The tag values (e.g. arcs tag, object summary tag, ...) are aways
written as the same sequence of bytes independent of byte order. But
when *reading* them back in, the code reads them as 32-bit values in
host byte order. For the comparisons to work correctly, this should
instead always read them as little-endian values.
Fixes PR 38121.
Reviewed By: marco-c
Differential Revision: https://reviews.llvm.org/D49132
llvm-svn: 336693
Summary:
This will make the behavior of __gcov_flush match the GCC behavior.
I would like to rename __gcov_flush to __llvm_gcov_flush (in case of programs linking to libraries built with different compilers), but I guess we can't for compatibility reasons.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: samsonov, vitalybuka, pcc, kcc, junbuml, glider, fhahn, eugenis, dvyukov, davidxl, srhines, chh, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48538
llvm-svn: 336365
__gcov_flush is hidden.
For applications to dump profiling data of selected .so files,
they can use dlsym to find and call llvm_gcov_flush in each .so file.
Differential Revision: https://reviews.llvm.org/D45454
llvm-svn: 336019
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Hopefully the Windows support is fixed now.
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320731
This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).
Patch by Rainer Orth!
Differential Revision: https://reviews.llvm.org/D40944
llvm-svn: 320726
Summary:
Fixes https://bugs.llvm.org/show_bug.cgi?id=34922.
Apparently, the mode in **fdopen** gets simply ignored and Windows only cares about the mode of the original **open**.
I have verified this both with the simple case from bug 34922 and with a full Firefox build.
Reviewers: zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38984
llvm-svn: 316048
The buildbots have shown that -Wstrict-prototypes behaves differently in GCC
and Clang so we should keep it disabled until Clang follows GCC's behaviour
llvm-svn: 312246
Clang 5 supports -Wstrict-prototypes. We should use it to catch any C
declarations that declare a non-prototype function.
rdar://33705313
Differential Revision: https://reviews.llvm.org/D36669
llvm-svn: 312240
The GCDA writer closed the arc file before unlocking it. This causes an
EBADF while unlocking the file, and opens us up to racy behavior.
Fixes PR26847.
llvm-svn: 262779
It thinks that these functions don't match the function pointer type
that they are passed with:
GCDAProfiling.c(578) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(579) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(580) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
llvm-svn: 260475
Summary: This change configures Windows builds to build the complier-rt profile support library (clang_rt.profile-i386.lib). Windows API incompatibilities in the compiler-rt profile lib are also fixed.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15830
llvm-svn: 256848
When the file is initialized, this patch checks whether the path
specifies a directory. If so, it creates the directory tree before
truncating the file.
Use default.profdata instead of pgo-data for default indexed profile name.
llvm-svn: 241824
This avoids crashing or corrupting data if multiple concurrent
processes write to the same .gcda file. This is hard to test, since
the previous behaviour was a data race that often worked out, and it
ignores errors in flock to fall back to the old racy behaviour so that
it won't degrade the behaviour on filesystems that don't support
flock.
llvm-svn: 234036
(thanks!) by deferring the free of the filename until we finish writing
the coverage data to that file.
Bill, let me know if you'd prefer a different approach!
llvm-svn: 184895
through Bill's patch:
1) Correctly test the file descriptor after the sceond attempt at
creating the file.
2) Make the filename a global so that we can issue error messages from
other routines.
3) Check errno in several places and print it out so that errors are
easier to track down.
I don't really expect any of these to fix the current failures I'm
seeing, but I'm hopeful they'll at least let me debug them.
llvm-svn: 184799
Using fwrite and fread was very *very* slow. The resulting code was multiple
times slower than GCC's implementation of gcov. Replace the fwrite/fread system
with an mmap() version.
If the `.gcda' file doesn't exist, we (re)allocate a buffer that we write
into. That gets written to the `.gcda' file in one chunk. If the `.gcda' file
already exists, we simply mmap() the file, modify the mapped data, and use
msync() to write the contents out to disk. It's much easier than implementing
our own buffering scheme, and we don't have to use fwrite's and fread's
buffering.
For those who are numbers-oriented, here are some timings:
GCC Verison
-----------
`.gcda' files don't exist: 23s
`.gcda' files do exist: 14s
LLVM Version (before this change)
---------------------------------
`.gcda' files don't exist: 28s
`.gcda' files do exist: 28s
LLVM Version (with this change)
-------------------------------
`.gcda' files don't exist: 18s
`.gcda' files do exist: 4s
It's a win-win-win-win-lose-win-win scenario!
<rdar://problem/13466086>
llvm-svn: 182563
The calls to fwrite/fread can be very expensive. GCC avoids this by using a
buffer to read and write from the file, thus limiting the number of fwrite/fread
calls.
<rdar://problem/13466086>
llvm-svn: 181924
Reid Kleckner