When LLVM_PROFILE_FILE is set incorrectly (e.g. multiple %c) and it
falls back to use `default.profraw` name, but continuous mode is still
set. This might cause signal bus in the following scenario.
LLVM_PROFILE_FILE is set incorrectly (with "%c%c") for process A and B.
Suppose A starts first and falls back to use `default.profraw` and
mmaped its file content to memory. Later B starts and also falls back to
use `default.profraw`, but it will truncate the file because online
merging is disable when reseting to `default.profraw`. When A tries to
update counter via mmaped memory, signal bus will occur.
This fixes it by disabling continuous mode when reset to
default.profraw.
This test relies on MSVC style linking details, such as -Wl,-dll
(which could be expressed with just "-shared", which would work
with MinGW too) and an implicitly created import library named
"<basename>.lib" (which isn't created when linking in MinGW mode).
This fixes running the compiler-rt tests in MinGW environments.
In `initializeProfileForContinuousMode`, we have already locked the profile file when merging is enabled, so there's no need to lock the same file second time in `openFileForMerging`.
On Linux/Darwin, the locking the same file twice doesn't cause any problem. But on Windows, it causes the problem to hang forever.
With this minor fix, continuous mode seems working with online merging on Windows.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D154748
We've been seeing this test return 31 instead of 32 for the "functions"
line in this test on our AArch64 bots.
One possible cause is some of the children not finishing in time
before the llvm-profdata commands are run, if the machine is heavily loaded.
Wait for all the children to finish before exiting the parent.
Reviewed By: zequanwu
Differential Revision: https://reviews.llvm.org/D109222
Replace D107203, because __llvm_profile_set_file_object is usually used when the
process doesn't have permission to open/create file. That patch trying to copy
from old profile to new profile contradicts with the usage.
Differential Revision: https://reviews.llvm.org/D108242
If there are no counters, an mmap() of the counters section would fail
due to the size argument being too small (EINVAL).
rdar://78175925
Differential Revision: https://reviews.llvm.org/D102735
Fix a buffer overrun that can occur when parsing '%c' at the end of a
filename pattern string.
rdar://74571261
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D97239
This test spawns 32 child processes which race to update counters on
shared memory pages. On some Apple-internal machines, two processes race
to perform an update in approximately 0.5% of the test runs, leading to
dropped counter updates. Deflake the test by using atomic increments.
Tested with:
```
$ for I in $(seq 1 1000); do echo ":: Test run $I..."; ./bin/llvm-lit projects/compiler-rt/test/profile/Profile-x86_64h/ContinuousSyncMode/online-merging.c -av || break; done
```
rdar://64956774
This is an alternative to the continous mode that was implemented in
D68351. This mode relies on padding and the ability to mmap a file over
the existing mapping which is generally only available on POSIX systems
and isn't suitable for other platforms.
This change instead introduces the ability to relocate counters at
runtime using a level of indirection. On every counter access, we add a
bias to the counter address. This bias is stored in a symbol that's
provided by the profile runtime and is initially set to zero, meaning no
relocation. The runtime can mmap the profile into memory at abitrary
location, and set bias to the offset between the original and the new
counter location, at which point every subsequent counter access will be
to the new location, which allows updating profile directly akin to the
continous mode.
The advantage of this implementation is that doesn't require any special
OS support. The disadvantage is the extra overhead due to additional
instructions required for each counter access (overhead both in terms of
binary size and performance) plus duplication of counters (i.e. one copy
in the binary itself and another copy that's mmapped).
Differential Revision: https://reviews.llvm.org/D69740
Make it possible to use online profile merging ("%m" mode) with
continuous sync ("%c" mode).
To implement this, the merged profile is locked in the runtime
initialization step and either a) filled out for the first time or b)
checked for compatibility. Then, the profile can simply be mmap()'d with
MAP_SHARED set. With the mmap() in place, counter updates from every
process which uses an image are mapped onto the same set of physical
pages assigned by the filesystem cache. After the mmap() is set up, the
profile is unlocked.
Differential Revision: https://reviews.llvm.org/D69586
Add support for continuously syncing profile counter updates to a file.
The motivation for this is that programs do not always exit cleanly. On
iOS, for example, programs are usually killed via a signal from the OS.
Running atexit() handlers after catching a signal is unreliable, so some
method for progressively writing out profile data is necessary.
The approach taken here is to mmap() the `__llvm_prf_cnts` section onto
a raw profile. To do this, the linker must page-align the counter and
data sections, and the runtime must ensure that counters are mapped to a
page-aligned offset within a raw profile.
Continuous mode is (for the moment) incompatible with the online merging
mode. This limitation is lifted in https://reviews.llvm.org/D69586.
Continuous mode is also (for the moment) incompatible with value
profiling, as I'm not sure whether there is interest in this and the
implementation may be tricky.
As I have not been able to test extensively on non-Darwin platforms,
only Darwin support is included for the moment. However, continuous mode
may "just work" without modification on Linux and some UNIX-likes. AIUI
the default value for the GNU linker's `--section-alignment` flag is set
to the page size on many systems. This appears to be true for LLD as
well, as its `no_nmagic` option is on by default. Continuous mode will
not "just work" on Fuchsia or Windows, as it's not possible to mmap() a
section on these platforms. There is a proposal to add a layer of
indirection to the profile instrumentation to support these platforms.
rdar://54210980
Differential Revision: https://reviews.llvm.org/D68351
