Now that i386-pc-solaris2.10 bootstraps again after the IRA merge, the first testsuite run revealed that all eh tests fail, affecting at least the g++ tests, ada/acats and libjava. The symptom is always the same; I take FAIL: g++.dg/eh/alias1.C execution test as an example. Running alias1.exe under gdb, I get the following stacktrace: Program received signal SIGABRT, Aborted. 0xfedf5cd5 in _lwp_kill () from /lib/libc.so.1 (gdb) up #1 0xfedf2b96 in thr_kill () from /lib/libc.so.1 (gdb) where #0 0xfedf5cd5 in _lwp_kill () from /lib/libc.so.1 #1 0xfedf2b96 in thr_kill () from /lib/libc.so.1 #2 0xfeda1307 in raise () from /lib/libc.so.1 #3 0xfed81719 in abort () from /lib/libc.so.1 #4 0xfee36b34 in uw_init_context_1 (context=0x8047560, outer_cfa=0x8047600, outer_ra=0xfef6e9fd) at /vol/gcc/src/gcc-dist/libgcc/../gcc/unwind-dw2.c:1249 #5 0xfee3716a in _Unwind_RaiseException (exc=0x8060e78) at unwind.inc:93 #6 0xfef6e9fd in __cxa_throw (obj=0x8060e98, tinfo=0x8050bfc, dest=0) at /vol/gcc/src/gcc-dist/libstdc++-v3/libsupc++/eh_throw.cc:81 #7 0x08050b51 in main () So the gcc_assert call in _Unwind_SetSpColumn causes this. Maybe one of the recent dwarf2 undwind patches has caused this? gcc was configured with --with-gnu-as --with-as=/usr/sfw/bin/gas, where /usr/sfw/bin/gas is gas 2.15. gcc/auto-host.h has auto-host.h:#define HAVE_GAS_CFI_DIRECTIVE 1 auto-host.h:#define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 0 I'm filing this under other since no other component seemed appropriate.
gas 2.15 is helplessly outdated and buggy. Can you retry with -fno-dwarf2-cfi-asm ?
Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail jakub at gcc dot gnu dot org writes: > gas 2.15 is helplessly outdated and buggy. Can you retry with > -fno-dwarf2-cfi-asm ? Unfortunately, passing in BOOT_CFLAGS='-g -O2 -fno-dwarf2-cfi-asm' didn't help (the value wasn't picked up from the environment). Even if I manually set BOOT_CFLAGS like that in the toplevel Makefile, it isn't passed down to the libgcc and libstdc++-v3 builds, and manually compiling an individual testcase with -fno-... isn't enough. If I add -fno-... to i386-pc-solaris2.10/libgcc/Makefile, rebuild libgcc and a testcase with -fno-..., the test passes. On the other hand, I tried bootstrapping with the current binutils 2.18 release, which makes no difference, so this doesn't seem to be a gas problem. Rainer
Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail I've done some further debugging: contrary to what gdb suggested, the reason for the abort is the gcc_assert call in unwind-dw2.c (uw_init_context_1): code = uw_frame_state_for (context, &fs); gcc_assert (code == _URC_NO_REASON); Single-stepping at the assembler level, I find that code is _URC_END_OF_STACK, i.e. _Unwind_Find_FDE () in uw_frame_state_for () returned NULL. Since this code is such a maze, I'm hard pressed to further debug this, so any guidance is appreciated. Rainer
Yep, same on SPARC.
See http://sourceware.org/ml/binutils/2008-09/msg00195.html Now someone needs to write a configure test for the compiler.
Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail ebotcazou at gcc dot gnu dot org writes: > See http://sourceware.org/ml/binutils/2008-09/msg00195.html Thanks for the info. > Now someone needs to write a configure test for the compiler. I'm a bit unsure how to test this right now: what I find is that C objects have read-only .eh_frame sections and use .cfi* directives, while C++, Java and Ada objects have read-write .eh_frame sections and still use .eh_frame sections directly emitted by the compiler. Rainer
> I'm a bit unsure how to test this right now: what I find is that C objects > have read-only .eh_frame sections and use .cfi* directives, while C++, Java > and Ada objects have read-write .eh_frame sections and still use .eh_frame > sections directly emitted by the compiler. I think that we should assemble some C code with CFI directives and see whether the resulting .eh_frame is read-only; if so, HAVE_GAS_CFI_DIRECTIVE must be set to 0 instead of 1. This should discriminate between 2.18 and upcoming 2.19. That the non-C compilers still emit .eh_frame directly is unexpected I'd think.
Subject: Re: [4.4 regression] All Solaris/x86 eh tests fail ebotcazou at gcc dot gnu dot org writes: > I think that we should assemble some C code with CFI directives and see whether > the resulting .eh_frame is read-only; if so, HAVE_GAS_CFI_DIRECTIVE must be set > to 0 instead of 1. This should discriminate between 2.18 and upcoming 2.19. That's what I did in my patch at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00249.html I could just take the current test code for gcc_cv_as_cfi_directive as is and inspect the object file with objdump on Solaris. Using C code directly with gcc -fexceptions -fdwarf2-cfi-asm didn't work since it relies upon the bootstrap compiler being gcc and sufficiently recent to support -fdwarf2-cfi-asm, leading to comparions failures upon a mismatch. > That the non-C compilers still emit .eh_frame directly is unexpected I'd think. I think I'll raise a separate PR for that and add rth to the Cc:. Rainer
If you have prehistoric assembler which doesn't support .cfi_personality directive, then .cfi_* directives can't be used for C++.
Patch preapproved by Alex: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01378.html
Subject: Bug 37463 Author: ro Date: Mon Nov 3 19:03:28 2008 New Revision: 141555 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141555 Log: PR other/37463 * configure.ac (gcc_cv_ld_ro_rw_mix): Move before gcc_cv_as_cfi_directive. (gcc_cv_as_cfi_directive) [*-*-solaris*]: Check if linker supports merging read-only and read-write sections or assembler emits read-write .eh_frame sections. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
Fixed.
> I'm a bit unsure how to test this right now: what I find is that C objects > have read-only .eh_frame sections and use .cfi* directives, while C++, Java > and Ada objects have read-write .eh_frame sections and still use .eh_frame > sections directly emitted by the compiler. The decision is made in dwarf2out_do_cfi_asm: /* Decide whether to emit frame unwind via assembler directives. */ int dwarf2out_do_cfi_asm (void) { int enc; #ifdef MIPS_DEBUGGING_INFO return false; #endif if (!flag_dwarf2_cfi_asm || !dwarf2out_do_frame ()) return false; if (!eh_personality_libfunc) return true; if (!HAVE_GAS_CFI_PERSONALITY_DIRECTIVE) return false; /* Make sure the personality encoding is one the assembler can support. In particular, aligned addresses can't be handled. */ enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2,/*global=*/1); if ((enc & 0x70) != 0 && (enc & 0x70) != DW_EH_PE_pcrel) return false; enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/0,/*global=*/0); if ((enc & 0x70) != 0 && (enc & 0x70) != DW_EH_PE_pcrel) return false; return true; } On Solaris with Sun ld, ASM_PREFERRED_EH_DATA_FORMAT is defined so that at least one of the 2 tests will always return false. Therefore the only way to have dwarf2out_do_cfi_asm return true is if (!eh_personality_libfunc) return true; The C++, Java and Ada compilers unconditionally register their personality routine, whereas the C compiler doesn't, even with -fexceptions: if there is no EH action in the code, it doesn't register it. Hence the discrepancy.