armel binaries using C++ exceptions likely broken

[Loïc Minier]

        Hi

 Matthias Klose and Ramana Radhakrishnan tracked down the openoffice.org
 startup crash on armel (LP #417009) to a serious gcc issue.  This might
 prompt for a rebuild of a bunch of packages between beta and final with
 a fixed toolchain.  Your input on the issue is welcome!

 Ramana describes the issue as follows:
    The problem was that the tools with gcc 4.4 and recent binutils now
    generating .eh_frame exception frame information using the GNU
    exception frame model while the ARM EABI mandates that the exception
    handling be done by the ARM Exception tables mechanism. So you had a
    case where the eh_frame sections had the data but in the form of
    absolute addresses.  This was the reason for the DT_TEXTREL entry in
    libc and librt. Now fixing this would fix the problem with our
    eglibc test failures and should also help with the Openoffice
    failure.

 A workaround is to build things with -fno-dwarf2-cfi-asm.  A patch was
 sent to gcc upstream to make it the default on ARM EABI, but the change
 is being debated as the real might be that gas is doing the wrong
 thing, not gcc.  See:
    http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00031.html

 After we fix gcc, we will have to rebuild glibc which was hit by this
 issue (check-textrel.out testcase was not passing anymore).  We will
 also update binutils to revert the workaround we had there (which was
 to disable some new linker checks -- that helped the oo.o issue).  Then
 we would like to look at rebuilding affected binaries.

 The affected binaries have not been identified yet; the test for
 deciding whether these are affected is to look for an .eh_frame section
 with __FRAME_END__.  All packages using -fexceptions are likely to need
 a rebuild, as well as C++ packages.  This likely means a high number of
 packages (crt.o is affected and is copied in all binaries).  The
 current plan is to check all shared libs for DT_TEXTREL and all
 binaries at the same time, and start by rebuilding leaf libraries
 first.  This is still being clarified/discussed.


 Input from ARM, toolchain, and release folks is highly appreciated.
 :-)

 Note that while this is a serious issue, especially in oo.o, it's
 probably not dramatically bad since we've been running armel desktops
 with only a handful of visible issues in applications.

   Thanks,
-- 
Loïc Minier