> > Thanks for the testcase. I meant to make one when alpha started having EH > > problems awhile back, but never got to it....Matthias, I believe this one > > will also catch the case that I saw on alpha. > > Interesting enough the program works as expected when compiled with > -static like "g++ -ggdb -o throw-2.95 throw.cc" (linker bug?)
Unlikely. The original gdb "backtrace" indicated that somebody was jumping to address 0. I think potential causes are: 1. dynamic initialization of a shared library has not been carried out. It would be interesting to verify that all shared libraries involved do have proper .init/.fini code, i.e. have been linked with the proper crt files. 2. dynamic initialization had initialized a different location than used when throwing the exception. That problem is known to occur when mismatching variants of the EH code in libgcc.a have been integrated into different shared libraries (or if both a libcc_s.so and copies of libgcc.a are used inconsistently): That would result in multiple copies of static variables of the EH variables. This isn't a problem as long as all libgcc functions resolve to the same shared object, but is a problem if they resolve to different libgcc copies; this happens when an out-of-libc.so copy has additional functions that are not in libgcc. 3. the dynamic linker has failed to perform all relocations properly. This is also unlikely. Regards, Martin
