llvm-g++ EH code doesn't work with GCC 4.3 libgcc_s.so.1

[sunfishcode]

Bugzilla Link	2998
Resolution	FIXED
Resolved on	Aug 18, 2009 13:04
Version	unspecified
OS	Linux
CC	@asl,@edwintorok,@nlewycky

Extended Description

Compiling this test from the test-suite:
SingleSource/Regression/C++/EH/ctor_dtor_count.cpp

with llvm-g++ on an Ubuntu "Intrepid" box, where /lib/libgcc_s.so.1 is
built from gcc-4.3 sources, results in an executable that hangs when
executed.

I dug up a libgcc_s.so.1 from an older package compiled from gcc-4.2 sources, and ran the same ctor_dtor_count executable without recompiling, forcing the older library to be used using LD_PRELOAD, and it executed successfully.

Compiling ctor_dtor_count with regular g++-4.2 and running the executable with the gcc-4.3 libgcc_s.so.1 does work.

I'm seeing this in both 32-bit and 64-bit executables.

Valgrind on the test executable found nothing interesting.

[llvmbot]

I think the gcc eh runtime changes caused problems for
gcc itself (I remember some discussion on the gcc mailing
list). Reading about this in the gcc archives may be a
good place to start.

[edwintorok]

Also using libgcc_s.so from llvm-gcc works: /home/edwin/llvm2.5/obj42/gcc/libgcc_s.so.1

Shouldn't llvm-gcc link the files it creates to its own runtime?

[sunfishcode]

Shouldn't llvm-gcc link the files it creates to its own runtime?

This would make the files dependent on an LLVM installation,
which is undesirable.

[llvmbot]

I think I found the reason. Due to LLVM not having
an equivalent of gcc's resx (though "unwind" could
be used for this) we have to jump through hoops to
get eh working correctly in the presence of llvm
inlining etc. The main (horrible) trick used is to
output a catch-all ("catch (...)") rather than a
cleanup when a cleanup is needed. This used to work
fine, but it looks like it breaks with libgcc from
gcc-4.3.

Consider the testcase:

int main(void) {
try { throw 1; }
catch (...) { throw; }
return 0;
}

In the IR we get:

    invoke void @​__cxa_rethrow() noreturn
                    to label %invcont1 unwind label %lpad9

lpad9: ; preds = %lpad
%eh_ptr10 = tail call i8* @​llvm.eh.exception() ; <i8*> [#uses=2]
%eh_select12 = tail call i64 (i8*, i8*, ...)* @​llvm.eh.selector.i64(i8* %eh_ptr10, i8* bitcast (i32 (...)* @​__gxx_personality_v0 to i8*), i8* null) ; [#uses=0]

Note how the selector is using a catch-all (null) rather than a cleanup (0).
This is semantically a cleanup (there to make sure __cxa_end_catch is called),
but as mentioned above we output this as a catch-all. If I change this to a
cleanup then all of a sudden everything works. It's not clear to me exactly
why using a catch-all is a problem here, but it seems it is.

I actually have a plan to get rid of all these nasty tricks, but it will
take a while.

[llvmbot]

This was caused by gcc commit 124837:

Index: gcc/ChangeLog

--- gcc/ChangeLog (revision 124836)
+++ gcc/ChangeLog (revision 124837)
@@ -1,3 +1,7 @@
+2007-05-18 Geoffrey Keating geoffk@apple.com
+

• • unwind-dw2.c (uw_identify_context): Use the CFA, not the IP.

2007-05-18 H.J. Lu hongjiu.lu@intel.com

PR target/31989

Index: gcc/unwind-dw2.c

--- gcc/unwind-dw2.c (revision 124836)
+++ gcc/unwind-dw2.c (revision 124837)
@@ -1526,7 +1526,7 @@
static inline _Unwind_Ptr
uw_identify_context (struct _Unwind_Context *context)
{

• return _Unwind_GetIP (context);

• return _Unwind_GetCFA (context);
  }

[llvmbot]

Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/084856.html

[edwintorok]

Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/084856.html

This is great news!
Thanks for tracking this down, will test it tomorrow.