================
@@ -328,6 +330,74 @@ TimerGroup::~TimerGroup() {
unlink();
}
+// ***REVIEWER***: I really don't know if this is warranted? I'm unaware of any
+// major environment where the stack grows up these days, but there's a
+// difference between me being unaware of such, and it not actually existing or
+// being a supported host platform.
+__attribute__((noinline)) static void
+stackGrowsDownResult(uintptr_t BaseStackPtr, bool *Result) {
+ *Result = llvm::getStackPointer() < BaseStackPtr;
+}
+__attribute__((noinline)) static bool
+stackGrowsDownInner(uintptr_t BaseStackPtr) {
+ // We use this to force a non-zero-sized stack frame, and we force it to live
+ // by using it to return the growth direction;
+ bool StackGrowsDown = false;
+ stackGrowsDownResult(BaseStackPtr, &StackGrowsDown);
+ return StackGrowsDown;
+}
+static bool stackGrowsDown() {
+ static bool GrowsDown = stackGrowsDownInner(llvm::getStackPointer());
+ return GrowsDown;
+}
+
+void TimerGroup::recoverFromCrash(uintptr_t StackBoundary) {
+ if (!isTimerGlobalsConstructed())
+ return;
+
+ // Reset the global timer group lock. We cannot call the destructor as it may
+ // currently be held by a dead thread, so we simply reinitialize in place.
+ sys::SmartMutex<true> &Lock = timerLock();
----------------
ojhunt wrote:
I'm going to see if I can actually do this correctly - force the timer and
timer group locks to introduce long/setjmp links to clean up correctly. It's
annoying because of course you want correctness by construction which forces us
into either a callback (forcing indentation) or macro horror
https://github.com/llvm/llvm-project/pull/219092
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits