Add -fcompact-unwind

This gives users the choice to enable __compact_unwind sections
when linking. These were previously hardcoded to be removed.

This can be used to solved the problem "C++ does not catch
exceptions when used with Haskell-main and linked by ghc",
https://gitlab.haskell.org/ghc/ghc/-/issues/11829

It does not change the default behavior, because I can not
estimate the impact this would have.

When Apple first introduced the compact unwind ABI, a number of
open source projects have taken the easy route of disabling it,
avoiding errors or even just warnings shortly after its
introduction.

Since then, about a decade has passed, so it seems quite possible
that Apple itself, and presumably many programs with it, have
successfully switched to the new format, to the point where the
old __eh_frame section support is in disrepair. Perhaps we should
get along with the program, but for now we can test the waters
with this flag, and use it to fix packages that need it.

1 files changed, 14 insertions, 0 deletions

diff --git a/docs/users_guide/phases.rst b/docs/users_guide/phases.rst
index 8b99939d98..c931268bbd 100644
--- a/docs/users_guide/phases.rst
+++ b/docs/users_guide/phases.rst
@@ -1322,3 +1322,17 @@ for example).
     that do runtime dynamic linking, where code dynamically linked in
     the future might require the value of a CAF that would otherwise
     be garbage-collected.
+
+.. ghc-flag:: -fcompact-unwind
+    :shortdesc: Instruct the linker to produce a `__compact_unwind` section.
+    :type: dynamic
+    :category: linking
+
+    :since: 9.4.1
+
+    This instructs the linker to produce an executable that supports Apple's
+    compact unwinding sections. These are used by C++ and Objective-C code
+    to unwind the stack when an exception occurs.
+
+    In theory, the older `__eh_frame` section should also be usable for this
+    purpose, but this does not always work.