This change allows us to do an end-to-end test of the FDR mode
implementation that uses the llvm-xray tooling to verify that what we
are both writing and reading the data in a consistent manner.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
LGTM
- Do these run as part of the "check-xray" target?
- We should update these to set the function time threshold flag to zero when we merge the unwriting patch in.
I volunteer to write a few supplemental test cases when that lands.
- Sets the threshold very high and checks that no functions appear in the log.
- Sets the threshold high, but have some functions that sleep. Check that invocations are erased when it makes sense and remain when eligible.
Yes. :)
- We should update these to set the function time threshold flag to zero when we merge the unwriting patch in.
Agreed.
I volunteer to write a few supplemental test cases when that lands.
- Sets the threshold very high and checks that no functions appear in the log.
- Sets the threshold high, but have some functions that sleep. Check that invocations are erased when it makes sense and remain when eligible.
Those sound like perfect individual tests to run indeed. :)
compiler-rt/trunk/test/xray/TestCases/Linux/fdr-thread-order.cc | ||
---|---|---|
3 |
How is that supposed to work? This test never cleans old logs, so they just accumulate in the current directory, and then this line picks one basically at random. |
compiler-rt/trunk/test/xray/TestCases/Linux/fdr-thread-order.cc | ||
---|---|---|
3 | The line after should take care of that, except for when the tests start failing. I've not found a way with lit to determine a cleanup mechanism that isn't order-dependent -- is there a feature that's useful there? Or is there a better way of spelling this so that the cleanup happens reliably? |
Oh. For some reason when I run it with manually with llvm-lit the temporary files keeping piling up in $PWD.
Somehow I don't see the problem any longer.
Anyway, if the cleanup is moved to the beginning of the test, stale logs would not affect future test runs.
How is that supposed to work?
This test never cleans old logs, so they just accumulate in the current directory, and then this line picks one basically at random.