os_test TA build reports duplicated __aeabi_unwind_cpp_pr0() definition

[etienne-lms]

Found a build issue introduced by 1a205ae ("Add regression 1031 (C++ support in TAs)") when OP-TEE built with CFG_UNWIND=n:

Issue found on both qemu_v7 and stm32mp1 OP-TEE setup.

.../build/../toolchains/aarch32/bin/arm-linux-gnueabihf-ld.bfd: .../toolchains/aarch32/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/libgcc_eh.a(unwind-arm.o): in function `__aeabi_unwind_cpp_pr0':
/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/src/gcc/libgcc/config/arm/unwind-arm.c:494: multiple definition of `__aeabi_unwind_cpp_pr0'; .../optee_os/out/arm/export-ta_arm32/lib/libutils.a(aeabi_unwind.o): .../optee_os/lib/libutils/ext/arch/arm/aeabi_unwind.c:9: first defined here
.../optee_os/out/arm/export-ta_arm32/mk/link.mk:109: recipe for target 'out/5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf' failed
make[3]: *** [out/5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf] Error 1

Seems __aeabi_unwind_cpp_pr0() is already defined in the toolchain (arm-linux-gnueabihf/8.3.0/libgcc_eh.a) and conflicts with the one exported by optee_os libutils.
I don't understand why this pops out only when CFG_UNWIND=n.

FYI I worked around this issue by adding weak attribute to the function in libutils.
(another workaround is to revert 1a205ae ):

Note: maybe this issue should be created in optee_os.

[jforissier]

FYI I worked around this issue by adding weak attribute to the function in libutils.

Sounds like a reasonable fix but I must admit I have not totally understood what's happening :-/ Here is what I know:

• CFG_UNWIND=y (the default) adds -funwind-tables to the C flags (for both Core and TA). Due to this flag, the linker adds dependencies to "personality routines" which are supposed to be used by the unwinder, as per the Arm Exception Handling ABI. (https://static.docs.arm.com/ihi0038/a/IHI0038A_ehabi.pdf section 9.2).
• Due to the above, and although our unwinders (in the TEE Core or in ldelf) do not use the personality routines, we need to have them defined somewhere. Which is the reason why commit OP-TEE/optee_os@923c1f34 has added them to libutils. Note they are added unconditionally (even when CFG_UNWIND is disabled).

Like you, I don't understand why CFG_UNWIND=n causes the issue, or rather I don't get why the C++ test links with no error when =y (the symbols are present in both libutils and libgcc_eh.a so why no link error?).

Perhaps the best way forward is to remove the problematic functions from libutils when CFG_UNWIND != y. Seems like the simplest option. Can you create a PR?

[etienne-lms]

Thanks @jforissier for your feedback.
P-R OP-TEE/optee_os#4040 created.