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
|
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| GCDAProfiling.c | ||
| InstrProfData.inc | ||
| InstrProfiling.c | ||
| InstrProfiling.h | ||
| InstrProfilingBuffer.c | ||
| InstrProfilingFile.c | ||
| InstrProfilingInternal.h | ||
| InstrProfilingMerge.c | ||
| InstrProfilingMergeFile.c | ||
| InstrProfilingNameVar.c | ||
| InstrProfilingPlatformDarwin.c | ||
| InstrProfilingPlatformLinux.c | ||
| InstrProfilingPlatformOther.c | ||
| InstrProfilingPort.h | ||
| InstrProfilingRuntime.cc | ||
| InstrProfilingUtil.c | ||
| InstrProfilingUtil.h | ||
| InstrProfilingValue.c | ||
| InstrProfilingWriter.c | ||
| WindowsMMap.c | ||
| WindowsMMap.h | ||