Bug 2225696

Created attachment 1977565 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Created attachment 1977566 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 1977567 [details]
state.log

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

What I've found so far is that Ahven's test suite intentionally raises an exception and tries to check that the exception was raised correctly, but exception propagation code somewhere in libgcc aborts the process instead of jumping to the exception handler.

Closer inspection reveals that the abortion is caused by a failing assertion in `_Unwind_SetGR` (libgcc, unwind-dw2.c, line 295). The register size loaded from `dwarf_reg_size_table[index]` appears to be 0 while 8 is expected (at least for for x86_64).

Inspection of `dwarf_reg_size_table` near the assertion shows that the array has not been initialized:

    (gdb) info symbol 0x435a50
    dwarf_reg_size_table in section .bss of /home/user/ahven/gnat_linux/tester

    (gdb) x/17xb 0x435a50
    0x435a50 <dwarf_reg_size_table>:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x435a58 <dwarf_reg_size_table+8>:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
    0x435a60 <dwarf_reg_size_table+16>:	0x00

However, further investigation reveals that there's another instance of `dwarf_reg_size_table`:

    (gdb) info address dwarf_reg_size_table
    Symbol "dwarf_reg_size_table" is static storage at address 0x7ffff7f15060.

This instance originates from the libgcc shared library and _has_ been initialized:

    (gdb) info symbol 0x7ffff7f15060
    dwarf_reg_size_table in section .bss of /lib64/libgcc_s.so.1

    (gdb) x/17xb 0x7ffff7f15060
    0x7ffff7f15060 <dwarf_reg_size_table>:	0x08	0x08	0x08	0x08	0x08	0x08	0x08	0x08
    0x7ffff7f15068 <dwarf_reg_size_table+8>:	0x08	0x08	0x08	0x08	0x08	0x08	0x08	0x08
    0x7ffff7f15070 <dwarf_reg_size_table+16>:	0x08

This immediately leads to the suspicion that the program is being linked incorrectly. Having a closer look at the build output reveals conflicting switches for `gnatbind`:

    /usr/bin/gnatbind -shared -o b__tester.adb <...> -static <...>
    /usr/bin/gnatbind -shared -o b__tap_tester.adb <...> -static <...>
    /usr/bin/gnatbind -shared -o b__perf_tester.adb <...> -static <...>

The `-static` switch is added via GPRbuild-file `gnat_linux/ahven_tests.gpr`.

Removing the `-static` switch - by either patching `ahven_tests.gpr` or overriding it using via Comfignat's `GNATBINDFLAGS` build parameter (i.e., add `GNATBINDFLAGS=-shared`) - solves the problem.

Thanks to Dennis for the analysis.

Passing -static to Gnatbind causes -static-libgcc to be passed to GCC for the linking. Overriding it with -shared causes -shared-libgcc to be used instead. The GCC manual has this to say about -shared-libgcc and -static-libgcc:

> 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’.
> 
> [...]
> 
> However, if a library or main executable is supposed to throw or
> catch exceptions, you must link it using the G++ driver, or using
> the option ‘-shared-libgcc’, such that it is linked with the shared
> ‘libgcc’.

That's exactly what fails here: Ahven.Assert in the library raises an exception that Assertion_Tests.Test_Assert_Equal in the test program is supposed to catch. Thus I think it's clear that this use of -static is wrong.

Worked around with "GNATBINDFLAGS=-shared".