C, -fexceptions, libgcc_s, and related matters on arm64

C, -fexceptions, libgcc_s, and related matters on arm64

[Dallman, John]

I work on a commercial mathematical modelling library, built from C code, and delivered on Linux as a .so. It has to be capable of having C++ exceptions thrown through it, as many of the applications that use it are C++.

On x86-64 CentOS 7, with GCC 4.8.3 driven by the LSB 5.0 lsbcc, I compile with -fexceptions, which causes some of my object files to need __gcc_personality_v0 and _Unwind_Resume, I link with -shared-libgcc and -lgcc_s. That satisfies the requirements for __gcc_personality_v0 and _Unwind_Resume, and allows C++ exceptions to be thrown from below me in the call stack, propagate through me, and be caught above me. That's fine.

I'm starting to build for arm64 on Ubuntu 20.04, with GCC 9.3 and no LSB tools involved. I use -fexceptions, but that does not generate any need for __gcc_personality_v0, _Unwind_Resume or any of the other symbols in libgcc_s.so. I'm a bit puzzled about this, and nervous about accepting it as normal. There are no Linux arm64 versions of the applications that use the library yet, so my ability to test C++ exception throwing through the library is limited to trivial programs: all of the test harnesses I have are C.

My x86-64 compile options are: /opt/lsb/bin/lsbcc -m64 -O2 -fno-strict-aliasing -fPIC -D _POSIX_SOURCE -D_POSIX_C_SOURCE=200809L -c -fexceptions -std=c99 -Wformat -Wformat-security

My arm64 compile options are similar: cc -march=armv8-a -ffp-contract=off -O -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=200112L -c -fexceptions -std=c99 -Wformat -Wformat-security -fstack-protector-strong -fno-strict-aliasing

Any suggestions?

Thanks in advance,

--
John Dallman
Siemens Digital Industries Software


-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: C, -fexceptions, libgcc_s, and related matters on arm64

[Florian Weimer]

* John via Gcc-help Dallman:

> My arm64 compile options are similar: cc -march=armv8-a -ffp-contract=off -O -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=200112L -c -fexceptions -std=c99 -Wformat -Wformat-security -fstack-protector-strong -fno-strict-aliasing
>
> Any suggestions?

Check -S output and see if references to the personality routine are
there.  Then proceed to the generated object files.

Maybe your AArch64 toolchain defaults to static linking?  Or the
compiler is not GCC and does not actually implement this GNU
extension?

RE: C, -fexceptions, libgcc_s, and related matters on arm64

[Dallman, John]

> Check -S output and see if references to the personality routine are there. Then proceed to the generated object files.

On x86-64, the personality is referenced, quite a lot, in the assembler output:

$ grep __gcc_personality pk/pk_bb.s
        .cfi_personality 0x9b,DW.ref.__gcc_personality_v0
        .globl  __gcc_personality_v0
        .cfi_personality 0x9b,DW.ref.__gcc_personality_v0
        .hidden DW.ref.__gcc_personality_v0
        .weak   DW.ref.__gcc_personality_v0
        .section        .data.DW.ref.__gcc_personality_v0,"awG",@progbits,DW.ref.__gcc_personality_v0,comdat
        .type   DW.ref.__gcc_personality_v0, @object
        .size   DW.ref.__gcc_personality_v0, 8
DW.ref.__gcc_personality_v0:
        .quad   __gcc_personality_v0

On arm64, it is not:

$  grep gcc_per pk/pk_bb.s
((no output))

> Maybe your AArch64 toolchain defaults to static linking?

It seems to be happily using dynamic linking. On x86-64:

$ ldd /path/to/libmine.so
        linux-vdso.so.1 =>  (0x00007ffec69bc000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5eaed0c000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5eaeaef000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5eae72e000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f5eae42c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5eb3c4f000)

And on arm64:

$ ldd /path/to/libmine.so
        linux-vdso.so.1 (0x0000ffff90cca000)
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff8d04d000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff8ceda000)
        /lib/ld-linux-aarch64.so.1 (0x0000ffff90c9a000)
        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff8ce2d000)

The difference is that the arm64 build does not reference libgcc_s.so.

> Or the compiler is not GCC and does not actually implement this GNU extension?

$ cc --version
cc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Any more ideas?

Thanks,

--
John Dallman
Siemens Digital Industries Software

> -----Original Message-----
> From: Florian Weimer <fw@deneb.enyo.de>
> Sent: 23 October 2021 13:38
> To: Dallman, John via Gcc-help <gcc-help@gcc.gnu.org>
> Cc: Dallman, John (DI SW PE OT PC PDE) <john.dallman@siemens.com>
> Subject: Re: C, -fexceptions, libgcc_s, and related matters on arm64
>
> * John via Gcc-help Dallman:
>
> > My arm64 compile options are similar: cc -march=armv8-a
> > -ffp-contract=off -O -fPIC -D_POSIX_SOURCE -
> D_POSIX_C_SOURCE=200112L
> > -c -fexceptions -std=c99 -Wformat -Wformat-security
> > -fstack-protector-strong -fno-strict-aliasing
> >
> > Any suggestions?
>
> Check -S output and see if references to the personality routine are there.
> Then proceed to the generated object files.
>
> Maybe your AArch64 toolchain defaults to static linking?  Or the compiler is
> not GCC and does not actually implement this GNU extension?
-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.