OS X: ld: warning: could not create compact unwind for _ffi_call_unix64

[altaic]

The OS X 10.6 linker now defaults to creating compact unwinds, which is a good thing, however the unwind info for _ffi_call_unix64 can't be represented in the compact format. This warning is issued any time ghc links, and many tests in the test suite fail due to the extra output:

ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame

Possible solutions:

• suppress the warning in ld; unfortunately this does not seem to be possible, since the only applicable option is -warn_compact_unwind which enables the already enabled-by-default warnings
• suppress the warning in ghc; I haven't really looked into this, but one could filter the text output from the linker to remove the warning
• entirely disable compact unwinds using -no_compact_unwind; this flag is undocumented, so I'm not certain about what it really does
• patch _ffi_call_unix64 in libffi to make it compatible with compact unwinds

Info about compact unwinds in OS X 10.6 is somewhat scarce, but man unwinddump has a bit:

When a C++ (or x86_64 Objective-C) exception is thrown, the runtime must unwind the
stack looking for some function to catch the exception.  Traditionally, the unwind
information is stored in the __TEXT/__eh_frame section of each executable as Dwarf
CFI (call frame information).  Beginning in Mac OS X 10.6, the unwind information is
also encoded in the __TEXT/__unwind_info section using a two-level lookup table of
compact unwind encodings.

The unwinddump tool displays the content of the __TEXT/__unwind_info section.

Relevant discussions:

 http://groups.google.com/group/llvm-dev/browse_thread/thread/8baba4531a9feb07/139c9eba3525ebe  http://groups.google.com/group/darwin-dev/browse_thread/thread/962f74bde0efaae4/cfb63dfb3ac34ce1

[altaic]

I inquired on the libffi mailing list about an upstream fix and received a response from the author of libffi, Anthony Green:

Thanks for these pointers.  I read the first thread and my summary is
that the EH unwind info format has changed in OS X 10.6 and GCC hasn't
caught up yet.

I'm not aware of any volunteers planning to update libffi to match this
change, but it sounds like it is required in order to support EH.
Volunteers welcome!

AG

In the meantime, I hacked out a patch for the testsuite that filters out the warnings. It's not intended to be any sort of fix for merging, but it is useful for examining the results of the testsuite until an actual fix is produced.

[igloo]

I'm not seeing any testsuite failures here. Is this problem new in XCode 4?

[igloo]

The messages on the libffi list are:

 http://sourceware.org/ml/libffi-discuss/2011/msg00109.html

 http://sourceware.org/ml/libffi-discuss/2011/msg00114.html

[altaic]

I do now have Xcode 4, however I believe the warning existed before I installed it. Iirc it appeared after I installed the 10.6.6 update.

[igloo]

I've just updated to 10.6.7 and still don't see it.

[altaic]

Replying to igloo:

I've just updated to 10.6.7 and still don't see it.

Sorry, I guess I was mistaken. Just to confirm, are you building ghc to target x86_64?

[igloo]

Replying to altaic:

Replying to igloo:

I've just updated to 10.6.7 and still don't see it.

Sorry, I guess I was mistaken. Just to confirm, are you building ghc to target x86_64?

Yes.

Incidentally, I'm hoping to hold off from installing XCode 4 until GHC 7.2.1 is out, so that a released compiler works out of the box for me.

[igloo]

Oh, I've just remembered that 7.0.3 works with XCode 4. I'll try upgrading now, then.

[batterseapower]

After I installed XCode4 I started getting lots of instances of this error:

ld: warning: could not create compact unwind for .LFB3: non-standard register 5 being saved in prolog

A validate run fails with:

Unexpected failures:
   cabal/cabal01           cabal01 [bad stderr] (normal)
   cabal/cabal04           cabal04 [bad stderr] (normal)
   codeGen/should_compile  2578 [bad stderr] (normal)
   driver                  driver062a [bad stderr] (normal)
   driver                  driver062b [bad stderr] (normal)
   driver                  driver062c [bad stderr] (normal)
   driver                  driver062d [bad stderr] (normal)
   driver                  driver062e [bad stderr] (normal)
   driver                  driver081a [bad stderr] (normal)
   driver                  driver081b [bad stderr] (normal)
   driver                  rtsopts001 [bad stderr] (normal)
   driver                  rtsopts002 [bad stderr] (normal)
   driver                  withRtsOpts [bad stderr] (normal)
   driver/1372             1372 [bad stderr] (normal)
   driver/1959             1959 [bad stderr] (normal)
   driver/T3007            T3007 [bad stderr] (normal)
   driver/recomp004        recomp004 [bad stderr] (normal)
   gadt                    gadt23 [bad stderr] (normal)
   lib/IO                  3307 [bad stderr] (normal)
   lib/IO                  T4113 [bad stdout] (normal)
   lib/IO                  environment001 [bad stderr] (normal)
   module                  mod179 [stderr mismatch] (normal)
   perf/compiler           T4801 [stat not good enough] (normal)
   perf/should_run         T2902 [bad stderr] (normal)
   perf/should_run         T3736 [bad stderr] (normal)
   programs/hs-boot        hs-boot [stderr mismatch] (normal)
   rename/prog006          rn.prog006 [bad stderr] (normal)
   rts                     4850 [bad stderr] (normal)
   rts                     T4059 [bad stderr] (normal)
   typecheck/bug1465       bug1465 [bad stderr] (normal)

These are almost all failing because of the extra warning text.

[thoughtpolice]

As I'm suffering from this problem too and it causes numerous testsuite failures, I've imported William's bandaid patch for the unwind frame warning from darcs to git, and put it here:

 http://github.com/thoughtpolice/testsuite/tree/5019-bandaid

Since this is apparently going to require a fix to libffi upstream to resolve properly, it would be nice to have this integrated into the testsuite for the time being (or an equivalent,) but it's damn ugly.

I'm using x86_64/GHC on OS X 10.6.8, XCode v4.0.2.

[dmp]

If I add -optl"-Wl,-no_compact_unwind" to the ghc command file (e.g. /usr/bin/ghc) the linker warnings are not generated. It seems to be an ok fix if we do not want to catch c++ or objective c exceptions in a Haskell program.

[chak]

This warning turns into a fatal error with Xcode 4.2, see #5293

[chak]

This is fixed by

commit 30ccc9f39dd2cf1ad14e6116778aa1fd94526c19
Author: Manuel M T Chakravarty <chak@cse.unsw.edu.au>
Date:   Wed Jul 27 23:05:01 2011 +1000

   On OS X x86_64, use "-Wl,-no_pie" and "-Wl,-no_compact_unwind" to avoid linker warnings

   - "-Wl,-no_pie" can be removed once GMP gets updated

on Lion (10.7) with Xcode 4.1. There is still (another) warning on Snow Leopard. I'd recommend to upgrade your OS.

I wonder whether the warning about the unwinds will go away once we can compile with clang. In that case, we could remove "-Wl,-no_compact_unwind". We should also be able to remove "-Wl,-no_pie" with a newer GMP.

I don't know how this all affects the 32bit build (the patch only applies to x86_64). Apple basically deprecated 32bit binaries with Lion.

Igloo, do you want to close the bug or leave it open as a reminder. (At least the priority can be downgraded, I think.)

[chak]

Regarding GMP, the GMP folks basically seem to say we should use the dynlib version of the library. I still think that the .a they are building makes no sense for Lion (OS X 10.7), but I'll have a look at changing my fix for GHC to use the dynlib code.

[igloo]

Punting to 7.6, but I think we should use an unpatched gmp.