Date: Sat, 4 Jan 2025 14:18:11 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: "mmel@freebsd.org" <mmel@FreeBSD.org> Cc: "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org> Subject: Re: git: caab831338f4 - main - Export additional __aeabi_ symbols from arm's libgcc_s Message-ID: <8531A9F2-3333-4C74-8DB7-2455C9AE070B@FreeBSD.org> In-Reply-To: <0ed7a6fa-12a5-4fd9-a77f-a4d49d0b3699@FreeBSD.org> References: <202412282118.4BSLIhVr001896@gitrepo.freebsd.org> <0ed7a6fa-12a5-4fd9-a77f-a4d49d0b3699@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Jan 2025, at 14:09, Michal Meloun <mmel@FreeBSD.org> wrote: >=20 > On 28.12.2024 22:18, Dimitry Andric wrote: >> The branch main has been updated by dim: >> URL: = https://cgit.FreeBSD.org/src/commit/?id=3Dcaab831338f4eeaa7455e981478be9fd= 414b7969 >> commit caab831338f4eeaa7455e981478be9fd414b7969 >> Author: Dimitry Andric <dim@FreeBSD.org> >> AuthorDate: 2024-12-28 21:17:13 +0000 >> Commit: Dimitry Andric <dim@FreeBSD.org> >> CommitDate: 2024-12-28 21:18:20 +0000 >> Export additional __aeabi_ symbols from arm's libgcc_s >> Some programs depend on these symbols, when they are = compiled for armv6 >> or armv7. Closes #1560 (slightly changed due to sorting of the = symbols). >> PR: 271087 >> Reported by: fuz >> Submitted by: jfc@mit.edu >> MFC after: 1 week >> --- >> lib/libgcc_s/arm/Symbol.map | 27 ++++++++++++++++++++++++++- >> 1 file changed, 26 insertions(+), 1 deletion(-) >> diff --git a/lib/libgcc_s/arm/Symbol.map = b/lib/libgcc_s/arm/Symbol.map >> index 92b54761d810..a426f823de5c 100644 >> --- a/lib/libgcc_s/arm/Symbol.map >> +++ b/lib/libgcc_s/arm/Symbol.map >> @@ -4,8 +4,33 @@ >> GCC_3.5 { >> _Unwind_Complete; >> _Unwind_VRS_Get; >> - _Unwind_VRS_Set; >> _Unwind_VRS_Pop; >> + _Unwind_VRS_Set; >> + __aeabi_d2h; >> + __aeabi_d2lz; >> + __aeabi_d2ulz; >> + __aeabi_f2h; >> + __aeabi_f2lz; >> + __aeabi_f2ulz; >> + __aeabi_h2f; >> + __aeabi_idiv; >> + __aeabi_idiv0; >> + __aeabi_l2d; >> + __aeabi_l2f; >> + __aeabi_lasr; >> + __aeabi_lcmp; >> + __aeabi_ldivmod; >> + __aeabi_llsl; >> + __aeabi_llsr; >> + __aeabi_lmul; >> + __aeabi_ui2d; >> + __aeabi_ui2f; >> + __aeabi_uidiv; >> + __aeabi_uidivmod; >> + __aeabi_ul2d; >> + __aeabi_ul2f; >> + __aeabi_ulcmp; >> + __aeabi_uldivmod; >> __aeabi_unwind_cpp_pr0; >> __aeabi_unwind_cpp_pr1; >> __aeabi_unwind_cpp_pr2; >=20 > I think the aeabi_ functions with floating point arguments were not = added correctly. By definition, they must be compiled with = -mfloat-abi=3Dsoftfp event if the rest of the library is compiled with = hardfp abi. >=20 > It is also not clear why they are added to lib/libgcc_s/arm/Symbol.map = and not to lib/libc/arm/aeabi/Symbol.map, where the other (some now = duplicated) aeabi_ symbols are. >=20 > Also, the list of aeabi_ functions in is not complete, although the = compiler_rt library contains them (__aeabi_f2d, __aeabi_f2iz...). >=20 > When I looked at it, I found another problem - the whole vfp suffix = dance in = https://cgit.freebsd.org/src/tree/lib/libcompiler_rt/Makefile.inc#n277 = is pointless, all these functions have the same extension in their name. = They are expected to be compiled (again with -mfloat-abi=3Dsoftfp) = together with the version without the suffix , and the rt linker will = select the appropriate version depending on the VFP presence. >=20 > In addition, the makefile searches for resources in the wrong order, > contrib/llvm-project/compiler-rt/lib/builtins is searched before > contrib/llvm-project/compiler-rt/lib/builtins/<arch>, so for example a = non-specific fp_mode is built, not an architecture-specific one. >=20 > What now? For me the most important question is in which map (and = namespace) should the aeabi_ symbols be defined (without breaking the = ABI for the user space). All good questions, for which I unfortunately do not know the answers. = It is probably best to make a follow-up bug to = https://bugs.freebsd.org/283484 where this patch originated. Or maybe = reopen it? -Dimitry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8531A9F2-3333-4C74-8DB7-2455C9AE070B>