Title: [293952] trunk/Source/bmalloc
Revision
293952
Author
mark....@apple.com
Date
2022-05-07 19:41:37 -0700 (Sat, 07 May 2022)

Log Message

Force PAS_ASSERT to generate different crash sites for each assertion.
https://bugs.webkit.org/show_bug.cgi?id=240209

Reviewed by Yusuke Suzuki.

Clang currently optimizes all crash sites into one in each function.  Hence, if we
get a crash address at the 1 crash site, we don't know which failed assertion got
us there.  This patch uses an asm statement to force Clang to emit a different
crash site for each assertion.

Benchmarks show that performance is neutral on both Jetstream2 and Speedometer2.

Size-wise, there is some increase.  The following is the "size" output on
_javascript_Core on M1:

          __TEXT.   __DATA  __OBJC  others    dec       hex
    old   19628032  180224  0       18792448  38600704  24d0000
    new   19644416  180224  0       19251200  39075840  2544000

    diff  16384     0       0       458752    475136

The increase in the "others" categories are mostly in the String Table, Symbol
Table, and Function Start Addresses.  These take up disk space but should not
impact RAM usage unless they are accessed by a a debugger.

* libpas/src/libpas/pas_utils.h:
(pas_assertion_failed):

Modified Paths

Diff

Modified: trunk/Source/bmalloc/ChangeLog (293951 => 293952)


--- trunk/Source/bmalloc/ChangeLog	2022-05-07 23:34:10 UTC (rev 293951)
+++ trunk/Source/bmalloc/ChangeLog	2022-05-08 02:41:37 UTC (rev 293952)
@@ -1,3 +1,33 @@
+2022-05-07  Mark Lam  <mark....@apple.com>
+
+        Force PAS_ASSERT to generate different crash sites for each assertion.
+        https://bugs.webkit.org/show_bug.cgi?id=240209
+
+        Reviewed by Yusuke Suzuki.
+
+        Clang currently optimizes all crash sites into one in each function.  Hence, if we
+        get a crash address at the 1 crash site, we don't know which failed assertion got
+        us there.  This patch uses an asm statement to force Clang to emit a different
+        crash site for each assertion.
+
+        Benchmarks show that performance is neutral on both Jetstream2 and Speedometer2.
+
+        Size-wise, there is some increase.  The following is the "size" output on
+        _javascript_Core on M1:
+
+                  __TEXT.   __DATA  __OBJC  others    dec       hex
+            old   19628032  180224  0       18792448  38600704  24d0000
+            new   19644416  180224  0       19251200  39075840  2544000
+
+            diff  16384     0       0       458752    475136
+
+        The increase in the "others" categories are mostly in the String Table, Symbol
+        Table, and Function Start Addresses.  These take up disk space but should not
+        impact RAM usage unless they are accessed by a a debugger.
+
+        * libpas/src/libpas/pas_utils.h:
+        (pas_assertion_failed):
+
 2022-04-27  Ross Kirsling  <rkirsl...@gmail.com>
 
         Unreviewed libpas build fix for PlayStation.

Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_utils.h (293951 => 293952)


--- trunk/Source/bmalloc/libpas/src/libpas/pas_utils.h	2022-05-07 23:34:10 UTC (rev 293951)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_utils.h	2022-05-08 02:41:37 UTC (rev 293952)
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2018-2021 Apple Inc. All rights reserved.
+ * Copyright (c) 2018-2022 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -193,10 +193,10 @@
 static PAS_ALWAYS_INLINE PAS_NO_RETURN void pas_assertion_failed(
     const char* filename, int line, const char* function, const char* _expression_)
 {
-    PAS_UNUSED_PARAM(filename);
-    PAS_UNUSED_PARAM(line);
-    PAS_UNUSED_PARAM(function);
-    PAS_UNUSED_PARAM(_expression_);
+#if PAS_COMPILER(GCC) || PAS_COMPILER(CLANG)
+    // Force each assertion crash site to be unique.
+    asm volatile("" : "=r"(filename), "=r"(line), "=r"(function), "=r"(_expression_));
+#endif
     __builtin_trap();
 }
 #endif /* PAS_ENABLE_TESTING -> so end of !PAS_ENABLE_TESTING */
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to