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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
@zequanwu I apologize for the delay in reviews. I've skimmed this change, and think it's in the right direction. I will try to respond with an in-depth review by the end of this week, if no one beats me to it.
compiler-rt/test/profile/ContinuousSyncMode/set-file-object.c | ||
---|---|---|
25 | Should this also verify that /profdir/<hash>profraw.old exists? IIUC it should, but counter_test() should have 0 coverage. |
Thanks, lgtm with one concern (see inline).
compiler-rt/lib/profile/InstrProfilingFile.c | ||
---|---|---|
1167 | You might already be aware of this limitation, but a heads-up just in case: the continuous sync mode does not handle keeping VP data up-to-date. While it's fine to write it out in the ProfileFileSize = 0 case, in general this is not a well-supported path (yet). |
@zequanwu We've been seeing this test fail seemingly randomly on our bots and I think the use of posix_spawn without then waiting for the children to finish might be the cause.
/home/tcwg-buildslave/worker/clang-aarch64-full-2stage/llvm/compiler-rt/test/profile/ContinuousSyncMode/set-file-object.c:25:11: error: MERGE: expected string not found in input // MERGE: Function count: 32 And we get: check:25'0 X error: no match found 10: Function count: 31 check:25'0 ~~~~~~~~~~~~~~~~~~~~
I think there may be a situation where on a heavily loaded system (we have a large server with many bots) where the last child doesn't write to the file before the llvm-profdata commands run.
I'm trying to reproduce locally to prove it but that's going to be tricky. Would it make sense to wait ("join", I think) on the children anyway to be safe here?
My framework project is hitting this error case in XC13 if (CounterMmap != CountersBegin) {....
Is there any troubleshooting I can perform on my end to resolve this? Code coverage shows at 0% for only one module.
You might already be aware of this limitation, but a heads-up just in case: the continuous sync mode does not handle keeping VP data up-to-date. While it's fine to write it out in the ProfileFileSize = 0 case, in general this is not a well-supported path (yet).