[Bug other/37463] New: [4.4 regression] All Solaris/x86 eh tests fail

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.


--
           Summary: [4.4 regression] All Solaris/x86 eh tests fail
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


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

--

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.4.0


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

------- Comment #1 from jakub at gcc dot gnu dot org  2008-09-15 11:05 -------
gas 2.15 is helplessly outdated and buggy.  Can you retry with
-fno-dwarf2-cfi-asm ?


--


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

------- Comment #2 from ro at techfak dot uni-bielefeld dot de  2008-09-16 15:02 -------
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


--


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

------- Comment #3 from ro at techfak dot uni-bielefeld dot de  2008-09-30 18:09 -------
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


--


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

------- Comment #4 from ebotcazou at gcc dot gnu dot org  2008-09-30 18:18 -------
Yep, same on SPARC.


--

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-09-30 18:18:17
               date|                            |


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

------- Comment #5 from ebotcazou at gcc dot gnu dot org  2008-09-30 18:19 -------
See http://sourceware.org/ml/binutils/2008-09/msg00195.html
Now someone needs to write a configure test for the compiler.


--


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

------- Comment #6 from ro at techfak dot uni-bielefeld dot de  2008-09-30 19:22 -------
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


--


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

------- Comment #7 from ebotcazou at gcc dot gnu dot org  2008-09-30 19:41 -------
> 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.


--


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

------- Comment #8 from ro at techfak dot uni-bielefeld dot de  2008-10-07 16:04 -------
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


--


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

------- Comment #9 from jakub at gcc dot gnu dot org  2008-10-13 10:00 -------
If you have prehistoric assembler which doesn't support .cfi_personality
directive, then .cfi_* directives can't be used for C++.


--


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

--

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

------- Comment #10 from jakub at gcc dot gnu dot org  2008-11-03 16:46 -------
Patch preapproved by Alex:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01378.html


--

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

------- Comment #11 from ro at gcc dot gnu dot org  2008-11-03 19:04 -------
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


--


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

------- Comment #12 from jakub at gcc dot gnu dot org  2008-11-03 19:23 -------
Fixed.


--

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

------- Comment #13 from ebotcazou at gcc dot gnu dot org  2008-11-19 18:51 -------
> 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.


--


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