================
@@ -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

Reply via email to