Hello, VxWorks has a custom definition of LIBGCC_SPEC to accommodate the variety of "modules" a user can build (dkm, sharedlib (-shared), static rtp, or rtp depending on shared libs (-non-static))
This change reworks that spec to better support configurations with
shared libraries enabled (patch coming) and document the variations.
The change also prepares for a possible dual-eh (dwarf+sjlj) setup,
which we (AdaCore) work on proposing. The impact on this patch is really
minimal and there's no functional impact at all in the interim.
The bulk of the change consists in the introduction of a couple of local
macros that instantiate the link options needed to include libgcc_eh in
the closure, with values depending on the configuration characteristics.
A few comments are added to explain the general idea and each of the
variations. Part of the changes consist in adding -lgcc after -lgcc_eh
to accommodate configurations where libgcc_eh legitimately resort to
libgcc functions on some targets, for example cas synchronisation routines
on aarch64.
We have been using this for a while in house for gcc-11 based toolchains
targetting a range of vxworks7r2 configurations (arm, aarch64, ppc, ppc64,
x86, x86_64, with shared libraries enabled for all the 64bit variants),
as well as for vxworks6.9 on powerpc.
I have verified that gcc-12 based toolchain for arm, ppc and ppc64 behave
as expected and performed a sanity check build for powerpc64-vxworks7r2 on
mainline.
Will commit shortly.
Cheers,
Olivier
2022-10-09 Olivier Hainque <hain...@adacore.com>
* config/vxworks (VX_LGCC_EH_SO0, VX_LGCC_EH_SO1): New internal macros.
(VXWORKS_LIBGCC_SPEC): Use them and document.
0001-Tigthen-the-addition-of-lgcc_eh-to-vxworks_libgcc_sp.patch
Description: Binary data
