[Bug ada/61027] New: gnatcmd gets SIGABRT during exception handling

[Bug ada/61027] New: gnatcmd gets SIGABRT during exception handling

[simon at pushface dot org]

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

            Bug ID: 61027
           Summary: gnatcmd gets SIGABRT during exception handling
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: simon at pushface dot org

Mac OS X 10.9.2 (darwin13.1.0), Xcode 5.1.1

The tool gnat (built as gnatcmd), as built in GCC, fails with SIGABRT while
unwinding an exception. None of the other tools show this behaviour (I suppose
they may not raise exceptions?), and gnatcmd is perhaps unusual in that it
raises an exception as part of its normal exit.

I rebuilt gnatcmd with the newly-built compiler, and the problem went away
(gnatcmd executed successfully).

This is a GDB session showing the problem.

(gdb) catch exception
Catchpoint 1: all Ada exceptions
(gdb) run list system.ads
Starting program: /Users/simon/tmp/gnatcmd/gnat list system.ads

Catchpoint 1, VMS_CONV.NORMAL_EXIT at 0x00000001000d0a8a in _ada_gnatcmd ()
    at /Users/simon/tmp/gcc-4.9.0/gcc/ada/gnatcmd.adb:2713
2713             raise Normal_Exit;
(gdb) n
44       end Debug_Raise_Exception;
(gdb) n
ada__exceptions__complete_occurrence (x=0x100a08710) at a-except.adb:943
943       end Complete_Occurrence;
(gdb) n
ada__exceptions__complete_and_propagate_occurrence (x=0x100a08710)
    at a-except.adb:952
952          Exception_Propagation.Propagate_Exception (X);
(gdb) s
ada__exceptions__exception_propagation__propagate_exceptionXn (
    excep=0x100a08710) at a-exexpr.adb:351
351       procedure Propagate_Exception (Excep : EOA) is
(gdb) s
353          Propagate_GCC_Exception (To_GCC_Exception
(Excep.Machine_Occurrence));
(gdb) s
ada__exceptions__exception_propagation__propagate_gcc_exceptionXn (
    gcc_exception=0x100a086d0) at a-exexpr.adb:311
311       procedure Propagate_GCC_Exception
(gdb) s
321          Unwind_RaiseException (GCC_Exception);
(gdb) s
__gnat_Unwind_RaiseException (e=0x100a086d0) at raise-gcc.c:1377
1377      return _Unwind_RaiseException (e);
(gdb) s
_Unwind_RaiseException (exc=0x100a086d0)
    at ../../../gcc-4.9.0/libgcc/unwind.inc:83
83    {
(gdb) n
88      uw_init_context (&this_context);
(gdb) n
83    {
(gdb) n
88      uw_init_context (&this_context);
(gdb) n
83    {
(gdb) n
88      uw_init_context (&this_context);
(gdb) n
83    {
(gdb) n
89      cur_context = this_context;
(gdb) n
83    {
(gdb) n
88      uw_init_context (&this_context);
(gdb) n

Program received signal SIGABRT, Aborted.
0x00007fff904ab866 in ?? ()

[Bug ada/61027] gnatcmd gets SIGABRT during exception handling

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027

--- Comment #2 from simon at pushface dot org ---
I just built 4.9.1 on Mac OS X 10.9.5 (Darwin 13.4.0), Xcode 6.0.1.

This problem goes away if GCC is configured with
--with-host-libstdcxx=-lstdc++.

For reference, the configuration flags, as reported by gcc, were

Target: x86_64-apple-darwin13
Configured with: ../gcc-4.9.1/configure \
  --prefix=/opt/gcc-4.9.1 \
  --disable-multilib \
  --disable-nls \
  --enable-languages=c,c++,ada,fortran,objc,obj-c++ \
  --host=x86_64-apple-darwin13 \
  --target=x86_64-apple-darwin13 \
  --build=x86_64-apple-darwin13 \
  --with-host-libstdcxx=-lstdc++
Thread model: posix
gcc version 4.9.1 (GCC)

[Bug ada/61027] gnatcmd gets SIGABRT during exception handling

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027

--- Comment #3 from simon at pushface dot org ---
Created attachment 34412
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34412&action=edit
Remove settings in gcc/ada/gcc-interface/Makefile.in (for Darwin)

[Bug ada/61027] gnatcmd gets SIGABRT during exception handling

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027

--- Comment #4 from simon at pushface dot org ---
I think my use of --with-host-libstdcxx=-lstdc++ to avoid this problem came at
it from slightly the wrong angle.

It seems to me that it's more to do with -static-libgcc and the 4.9 change to
use the C++ compiler as the basis for builds.

In https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html it says

<<<
-shared-libgcc
-static-libgcc
On systems that provide libgcc as a shared library, these options force the use
of either the shared or static version, respectively. If no shared version of
libgcc was built when the compiler was configured, these options have no
effect.

There are several situations in which an application should use the shared
libgcc instead of the static version. The most common of these is when the
application wishes to throw and catch exceptions across different shared
libraries. In that case, each of the libraries as well as the application
itself should use the shared libgcc.

Therefore, the G++ and GCJ drivers automatically add -shared-libgcc whenever
you build a shared library or a main executable, because C++ and Java programs
typically use exceptions, so this is the right thing to do.

If, instead, you use the GCC driver to create shared libraries, you may find
that they are not always linked with the shared libgcc. If GCC finds, at its
configuration time, that you have a non-GNU linker or a GNU linker that does
not support option --eh-frame-hdr, it links the shared version of libgcc into
shared libraries by default. Otherwise, it takes advantage of the linker and
optimizes away the linking with the shared version of libgcc, linking with the
static version of libgcc by default. This allows exceptions to propagate
through such shared libraries without incurring relocation costs at library
load time.

However, if a library or main executable is supposed to throw or catch
exceptions, you must link it using the G++ or GCJ driver, as appropriate for
the languages used in the program, or using the option -shared-libgcc, such
that it is linked with the shared libgcc.
>>>

and --with-host-libstdcxx=-lstdc++ does this as a side-effect when building
gnattools/.

This doesn't work when building a cross-compiler, because the tools are built
by gcc/ada/gcc-interface/Makefile.in which contains

   # Link flags used to build gnat tools.  By default we prefer to statically
   # link with libgcc to avoid a dependency on shared libgcc (which is tricky
   # to deal with as it may conflict with the libgcc provided by the system).
   GCC_LINK_FLAGS=-static-libstdc++ -static-libgcc

(there's a later setting in the target_os~=darwin section, too, just
-static-libstdc++ this time).

***********
* As a side question, is it proper for the Ada makefiles to override
* the decisions made in the top-level configure/Makefile settings?
***********

So I patched these out (pr61027-1.diff) and configured the cross-compiler with
--with-stage1-libs=no --with-stage1-ldflags=no (these affect the top-level
settings of LDFLAGS); the cross-compiler built OK and arm-eabi-gnat doesn't
give the SEGV.

I expect the same flags would be right for a --disable-bootstrap build. I
haven't yet tried the equivalent for a full build (--with-boot-libs=no
--with-boot-ldflags=no).

It seems likely that this is a Darwin problem only; I don't know how to
approach this as a top-level issue (do other languages use exceptions? given
the recommendations above re: -static-libgcc, should the configure.ac default
settings of stage1_ldflags and poststage1_ldflags include -static-libgcc?)

[Bug ada/61027] gnatcmd gets SIGABRT during exception handling

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027

--- Comment #7 from simon at pushface dot org ---
I think we should close this: no such problem with GCC 11.2.0 on Darwin 21.4.0.

[Bug ada/61027] gnatcmd gets SIGABRT during exception handling

[charlet at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027

Arnaud Charlet <charlet at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
                 CC|                            |charlet at gcc dot gnu.org
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #8 from Arnaud Charlet <charlet at gcc dot gnu.org> ---
Closing