[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271

howarth at nitro dot med.uc.edu gcc-bugzilla@gcc.gnu.org
Wed Jan 23 04:01:00 GMT 2013


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

--- Comment #19 from Jack Howarth <howarth at nitro dot med.uc.edu> 2013-01-23 04:01:17 UTC ---
(In reply to comment #12)
> BTW, the reason this works when forcing the instrumented path as Torvald
> suggested (comment #7) is because when f1() is instrumented, the call to
> __cxa_allocate_exception is also instrumented and we actually call:
> 
> dyld_stub__ITM_cxa_allocate_exception() -> _ITM_cxa_allocate_exception, which
> is defined in libitm/eh_cpp.cc:
> 
> void *
> _ITM_cxa_allocate_exception (size_t size)
> {
>   void *r = __cxa_allocate_exception (size);
>   gtm_thr()->cxa_unthrown = r;
>   return r;
> }
> 
> Assembly single stepping through the above shows that the call to
> __cxa_allocate_exception (through dyld_stub___cxa_allocate_exception) has a
> correct stub, not this "return 0" nonsense I describe in comment #10.

I appears that the undesired __cxa_allocate_exception) symbol defined in the
resulting a.out is coming from the -lcrttme.o linkage added  by the spec for
-fgnu-tm on darwin. I drop  -lcrttme.o from the linkage...

/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.8.2
-weak_reference_mismatches non-weak -o a.out -lcrttms.o
-L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin12.2.0/4.8.0
-L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin12.2.0/4.8.0/../../.. a.o -lstdc++
-litm -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -lcrttme.o -v

the testcase runs fine.



More information about the Gcc-bugs mailing list