forked from OSchip/llvm-project
ff3227e77d
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/D22613 https://reviews.llvm.org/D22614 Differential Revision: https://reviews.llvm.org/D34797 llvm-svn: 306710 |
||
---|---|---|
.. | ||
BlocksRuntime | ||
asan | ||
builtins | ||
cfi | ||
dfsan | ||
esan | ||
interception | ||
lsan | ||
msan | ||
profile | ||
safestack | ||
sanitizer_common | ||
scudo | ||
tsan | ||
ubsan | ||
xray | ||
CMakeLists.txt | ||
lit.common.cfg | ||
lit.common.configured.in |