[Mac] Redo NSException handling, and generate better stacks for C++ exceptions.

base/mac/call_with_eh_frame.h

Index: base/mac/call_with_eh_frame.h
diff --git a/base/mac/call_with_eh_frame.h b/base/mac/call_with_eh_frame.h
new file mode 100644
index 0000000000000000000000000000000000000000..1f7d5e0dec80c291efff67930a70c552e8f678d1
--- /dev/null
+++ b/base/mac/call_with_eh_frame.h
@@ -0,0 +1,26 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef BASE_MAC_CALL_WITH_EH_FRAME_H_
+#define BASE_MAC_CALL_WITH_EH_FRAME_H_
+
+#include "base/base_export.h"
+
+namespace base {
+namespace mac {
+
+// Invokes the specified block in a stack frame with a special exception
+// handler. This function creates an exception handling stack frame that
+// specifies a custom C++ exception personality routine, which terminates the
+// search for an exception handler at this frame.
+//
+// The purpose of this function is to prevent a try/catch statement in system
+// libraries, acting as a global exception handler, from handling exceptions
+// in such a way that disrupts the generation of useful stack traces.
+void BASE_EXPORT CallWithEHFrame(void (^block)(void));

[Scott Hess - ex-Googler, 2015/07/06 22:34:04]

Most of the users of this are functions which take no parameters and return
nothing.  Basically exactly like the block.  How much overhead does a block add
in this case?  Also, as used would there be any benefit to constructing the
block once and re-using it?

I realize that it's entirely possible that this bit of overhead is trivial
relative to the rest.  On the other hand, it's all deeply embedded so it's
reasonable to work a little harder.  If that's even possible, though.

[Robert Sesek, 2015/07/07 22:26:17]

The keyword here is "most", which is why I went with the block-based approach.
The issue is the one or two places where the arity differs, and that then
requires a whole new CallWithEHFrame just for that, exploding the size of the .S
file.

The blocks should be relatively low overhead. Blocks are basically a
compiler-generated function and some special memory space for any captured
variables (where this memory lives depends on the type of block). In this case,
the blocks should be "stack blocks", meaning the block storage space is just a
little extra allocation on the stack. That should be relatively negligble. I can
probably microbench this if you'd like, but I was just going to rely on Telemtry
to make sure that it's OK.

[Scott Hess - ex-Googler, 2015/07/07 22:34:31]

OK.  Mostly performance was the only thing I could legitimately noodle about. 
And Cocoa probably builds blocks like there's no tomorrow anyhow.

+
+}  // namespace mac
+}  // namespace base
+
+#endif  // BASE_MAC_CALL_WITH_EH_FRAME_H_