[PATCH] D32259: [XRay] [compiler-rt] - Fix standalone build test and XFAIL a test.

[Keith via Phabricator via llvm-commits]

kpw added a comment.

On a related note, do we have a test case in the FDR log reader tests that checks what we do when for example we cannot find the entry record for an unmatched exit record?

We don't have that, but the reader will allow that currently. We may have to be careful about assertions like that due to potential StronglyConnectedComponent optimizations. I don't know if optimizations would go so far as to jump to an alternative prologue that saves less registers or something crazy like that. Our analysis would be hosed for at least a portion of the program if that happened though. Where is it better to fail?

I think this test is flaky by construction either due to a race condition (f2 may have already run before the patching happened), or there's some other thing causing f2's records to not show up (maybe something to do with the changes made recently to check the cpu frequency the first time the handler is called).

It's possible that added I/O and indeterminism tip the function over the unwriting heuristic. There is definitely a cold start for the first function, it makes calls to get metadata in order.
Adding xray_fdr_log_func_duration_threshold_us to that test is probably a good idea, but it doesn't make the test pass for me. The number of ticks to qualify for unwrite could be behaving weird if that data isn't managed across threads correctly though...


https://reviews.llvm.org/D32259