freebsd-src/lib/libgcc_s/Versions.def


GCC_3.0 {
};

GCC_3.3 {
} GCC_3.0;

GCC_3.3.1 {
} GCC_3.3;

GCC_3.4 {
} GCC_3.3.1;

GCC_3.4.2 {
} GCC_3.4;

GCC_3.4.4 {
} GCC_3.4.2;

GCC_3.5 {
} GCC_3.4.4;

GCC_4.0.0 {
} GCC_3.5;

GCC_4.2.0 {
} GCC_4.0.0;

GCC_4.3.0 {
} GCC_4.2.0;

GCC_4.6.0 {
} GCC_4.3.0;

GCC_7.0.0 {
} GCC_4.6.0;
Fix llvm-libunwind userspace build on ARM GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or EHABI or whatever it's called. Export the same ones from LLVM-libunwind's libgcc_s, on ARM. As part of this, convert libgcc_s from a direct Version.map to one constructed from component Symbol.map files. This allows the ARM-specific Symbol.map to be included only on ARM. Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match non-ARM definitions and ARM-specific expectations in libcxxrt / libcompiler_rt. No functional change intended for non-ARM architectures. This commit does not actually flip the switch for ARM defaults from libgcc to llvm-libunwind, but makes it possible (to compile, anyway). 2019-11-05 03:20:40 +00:00
			`GCC_3.0 {`
			`};`

			`GCC_3.3 {`
			`} GCC_3.0;`

			`GCC_3.3.1 {`
			`} GCC_3.3;`

			`GCC_3.4 {`
			`} GCC_3.3.1;`

			`GCC_3.4.2 {`
			`} GCC_3.4;`

			`GCC_3.4.4 {`
			`} GCC_3.4.2;`

			`GCC_3.5 {`
			`} GCC_3.4.4;`

			`GCC_4.0.0 {`
			`} GCC_3.5;`

			`GCC_4.2.0 {`
			`} GCC_4.0.0;`

			`GCC_4.3.0 {`
			`} GCC_4.2.0;`
Export various 128 bit long double functions from libgcc_s.so.1 These were already compiled for some time on aarch64 and riscv, by including lib/libcompiler_rt/Makefile.inc, but never exported in the shared library. Since gcc exports these under version GCC_4.6.0, we do the same. This review should replace D11482 for now. For e.g. amd64 more work is still to be done, as compiler-rt does not seem to support 128 bit long double math for that architecture. Reviewed by: cem MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D28690 2021-06-14 20:17:05 +01:00
			`GCC_4.6.0 {`
			`} GCC_4.3.0;`
libgcc_s: expose __divmoddi4 on i386 GCC has used this for some time (since 7.0) and apparently we were getting away with using the hidden symbol, but when linking with --no-undefined-version we get an error unless it's properly exported. (For anyone who wonders at the assymetry, __udivmoddi4 is indeed much older and was introduced with GCC 3.0.) MFC after: 3 days Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D44878 2024-04-19 22:52:42 +01:00
			`GCC_7.0.0 {`
			`} GCC_4.6.0;`