* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.

EHFrame{N} IIRC is a special cue to ld64 that it should treat the unwind
in the object as "special/legacy" .. [these days everything is .cfi_xxxx
(except, cctools-as, as you noted)] .. without that much confusion arises
with ld64's atom-isation of the eh_frame section.

xxxx.eh labels are not needed for darwin ld64 >= 85.2.1 (i.e. darwin9,
xcode 3.1.4) to all intents and purposes, that's all that matters now,
since I think that anyone trying to build on 10.4/darwin8/xcode2.5 would
have to use a later ld64 (from odcctools) for other reasons.

Darwin aligns long-double to 16, and thus all of the long double
tests were failing due to not honoring that. We ought to be able
to devise a test case for GCC using __attribute__((aligned)) that
would have failed too.

aka GCC PR libffi/60073, to the rewritten Sparc codebase.
Supposedly, we should have seen failures with the existing
libffi.call/cls_double_va.c testcase, but I hadn't.
Perhaps a gcc newer than 4.6.3 is required to see that...