Fuchsia is no longer treated as UNIX which means we need to explicitly
enable building of shared versions of runtimes.
Differential Revision: https://reviews.llvm.org/D46609
llvm-svn: 331922
The profile library was missing some includes and was erroneously using
ftruncate. WinASan was using `= {0}` to initialize structs, which
creates -Wmissing-field-initializers and -Wmissing-braces warnings with
clang. Use `= {}` instead, since this is C++.
llvm-svn: 330616
This patch fixes the following issues:
(1) The strong definition of the merge hook function was not working which
breaks the online value profile merging. This patch removes the weak
attribute of VPMergeHook and assigns the value dynamically.
(2) Truncate the proifle file so that we don't have garbage data at the end of
the file.
(3) Add new __llvm_profile_instrument_target_value() interface to do the value
profile update in batch. This is needed as the original incremental by 1
in __llvm_profile_instrument_target() is too slow for online merge.
Differential Revision: https://reviews.llvm.org/D44847
llvm-svn: 328987
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:
This patch implements flock for Windows, needed to make gcda writing work in a multiprocessing scenario.
Fixes https://bugs.llvm.org/show_bug.cgi?id=34923.
Reviewers: zturner
Reviewed By: zturner
Subscribers: rnk, zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D38891
llvm-svn: 317705
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
Summary: In the current implementation, the defaul number of values per site tracked by value profiler is 8, which is too small and could introduce inaccuracies to profile. Changing it to 16 will be able to gain more accurate value profiler.
Reviewers: davidxl, tejohnson
Reviewed By: tejohnson
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D35964
llvm-svn: 309388
Users can specify the path a raw profile is written to by passing
-fprofile-instr-generate=<path>, but this functionality broke on Darwin
after __llvm_profile_filename was made weak [1], resulting in profiles
being written to "default.profraw" even when <path> is specified.
The situation is that instrumented programs provide a weak definition of
__llvm_profile_filename, which conflicts with a weak redefinition
provided by the profiling runtime.
The linker appears to pick the 'winning' definition arbitrarily: on
Darwin, it usually prefers the larger definition, which is probably why
the instrprof-override-filename.c test has been passing.
The fix is to move the runtime's definition into a separate object file
within the archive. This means that the linker won't "see" the runtime's
definition unless the user program has not provided one. I couldn't
think of a great way to test this other than to mimic the Darwin
failure: use -fprofile-instr-generate=<some-small-path>.
Testing: check-{clang,profile}, modified instrprof-override-filename.c.
[1] [Profile] deprecate __llvm_profile_override_default_filename
https://reviews.llvm.org/D22613https://reviews.llvm.org/D22614
Differential Revision: https://reviews.llvm.org/D34797
llvm-svn: 306710
Introduces a 'owner' struct to include the overridable write
method and the write context in C.
This allows easy introdution of new member API to help reduce
profile merge time in the follow up patch.
llvm-svn: 306432
And also r295364 [PGO] remove unintended debug trace. NFC
I removed the test case: it's hard to write synchronized test b/w processes
in this framework. I will revisit the test-case later.
llvm-svn: 298113
This patch adds profile run time support to profile a range of values.
This interface will be used in profiling the size of memory intrinsic calls.
Differential Revision: http://reviews.llvm.org/D28964
llvm-svn: 297895
Summary:
We found a nondeterministic behavior when doing online profile merging
for multi-process applications. The application forks a sub-process and
sub-process sets to get SIGKILL when the parent process exits,
The first process gets the lock, and dumps the profile. The second one
will mmap the file, do the merge and write out the file. Note that before
the merged write, we truncate the profile.
Depending on the timing, the child process might be terminated
abnormally when the parent exits first. If this happens:
(1) before the truncation, we will get the profile for the main process
(2) after the truncation, and before write-out the profile, we will get
0 size profile.
(3) after the merged write, we get merged profile.
This patch temporarily suspend the SIGKILL for PR_SET_PDEATHSIG
before profile-write and restore it after the write.
This patch only applies to Linux system.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: xur, llvm-commits
Differential Revision: https://reviews.llvm.org/D29954
llvm-svn: 295364
Summary: In profile data paths, we replace "%h" with the hostname of the machine the program is running on. On Windows, we used gethostname() to obtain the hostname. This requires linking with ws2_32. With this change, we instead get the hostname from GetComputerNameExW(), which does not require ws2_32.
Reviewers: rnk, vsk, amccarth
Subscribers: zturner, ruiu, hans
Differential Revision: https://reviews.llvm.org/D27178
llvm-svn: 288146
This makes __llvm_profile_set_filename() work across dylib boundaries on
Darwin.
This functionality was originally meant to work on all platforms, but
was moved to a Linux-only directory with r272404. The root cause of the
test failure on Darwin was that lprofCurFilename was not marked weak.
Each dylib maintained its own copy of the variable due to the two-level
namespace.
Tested with check-profile (on Darwin). I don't expect this to regress
other platforms.
Differential Revision: https://reviews.llvm.org/D25707
llvm-svn: 284440
This reverts commit r282294. It breaks a Linux bot:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12180
It looks like the test checks that __llvm_profile_set_filename() alters the raw
profile filename in both the dylib and the main program. Now that
lprofCurFilename is hidden, this can't work, and we get two profiles (one for
the call to "main" and one for "func").
Back this change out so that we don't affect external users.
llvm-svn: 282304
This patch builds on LLVM r279776.
In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth.
The three steps I abstract are:
(1) Add a top-level target (i.e asan, msan, ...)
(2) Set the target properties for sorting files in IDE generators
(3) Make the compiler-rt target depend on the top-level target
The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name.
The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings.
With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is:
> cmake [...]
> ninja runtimes-configure
> ninja asan
The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build.
Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats).
llvm-svn: 279863
The API is intended to be used by user to do fine
grained (per-region) control of profile dumping.
Differential Revision: http://reviews.llvm.org/D23106
llvm-svn: 278092
Petr Hosek