This change removes the dependency on C++ standard library
types/functions in the implementation of the buffer queue. This is an
incremental step in resolving llvm.org/PR32274.
Details
Diff Detail
- Build Status
Buildable 11369 Build 11369: arc lint + arc unit
Event Timeline
compiler-rt/lib/xray/xray_buffer_queue.cc | ||
---|---|---|
68 | I'm slightly worried about what happens if we mark this "true", then a signal happens, the handler will be instrumented and this thing will be reentered and succeeds past the mutex-guarded thing at the bottom. We will resume afterwards and continue with incrementing First yet again, possibly wasting a buffer. SpinMutex is clever enough to yield in case there is a different thread waiting (which isn't here) but not to be aware of signal processing. I think this should be addressed in a different diff though, using a lock-less mechanism. Shouldn't be too tricky for this simple case. | |
compiler-rt/lib/xray/xray_buffer_queue.h | ||
39 | I was having a bit of a problem realizing whether this means "is being used" or "has been used". Maybe you can think of a small comment to improve this, maybe not. |
compiler-rt/lib/xray/xray_buffer_queue.cc | ||
---|---|---|
68 | This 'Found' is in the process of just finding whether we own the buffer. It's also outside the critical section for a reason, since we never update OwnedBuffers anywhere outside the constructor. There are potential issues with the signal-safety of this function, but we have another synchronisation mechanism (recursion guard) that must guard us against having an instrumented signal handler coming in while already in the process of handling the event. | |
compiler-rt/lib/xray/xray_buffer_queue.h | ||
39 | I'm not sure why the distinction matters. |
I was having a bit of a problem realizing whether this means "is being used" or "has been used". Maybe you can think of a small comment to improve this, maybe not.