[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

["iains at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|powerpc-apple-darwin9.8.0   |*-apple-darwin{8,9,10}
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.06.26 17:37:00
          Component|bootstrap                   |target
                 CC|                            |dominiq at lps dot ens.fr
               Host|powerpc-apple-darwin9.8.0   |*-apple-darwin{8,9,10}
         AssignedTo|unassigned at gcc dot       |iains at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1
            Summary|libstdc++ (dylib) is built  |gcc emits frame (epilogue)
                   |with an erroneous           |info incompatible with the
                   |dependency towards /usr/lib |darwin
                   |                            |{8,9}-unwinder,10-compacter
              Build|powerpc-apple-darwin9.8.0   |*-apple-darwin{8,9,10}

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> 2011-06-26 17:37:00 UTC ---
This bug has been around since part way through 4.5.

Unfortunately, it is somewhat hidden in the test-suite since the latter
interposes the newly-built libgcc ahead of the system version (because
DYLD_LIBRARY_PATH is set to point to ./gcc, of necessity).

There are two steps needed to deal with this fully:

(a) fix things so we don't emit epilogue info in unwind frames for darwin 8,9
and 10 (compacter).

The patch currently attached is OK on 4.6.x - but the emitting of unwind frames
has been recently vec-ified which means it will need some re-work for trunk.

(b) fix the darwin libgcc build process so that we only export the _ext symbols
from newly-built libgcc when this is only supporting the ext.

* (b) will also solve the library ordering issues when -{force}_flat_namespace
is used.

I have another patch in progress that is a first attempt at (b) - (not yet
ready to post).