Re: git: caab831338f4 - main - Export additional __aeabi_ symbols from arm's libgcc_s

On 4 Jan 2025, at 14:09, Michal Meloun <mmel@FreeBSD.org> wrote:
> 
> 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=caab831338f4eeaa7455e981478be9fd414b7969
>> 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;
> 
> I think the aeabi_ functions with floating point arguments were not added correctly. By definition, they must be compiled with -mfloat-abi=softfp event if the rest of the library is compiled with hardfp abi.
> 
> 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.
> 
> Also, the list of aeabi_ functions in is not complete, although the compiler_rt library contains them (__aeabi_f2d, __aeabi_f2iz...).
> 
> 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=softfp) together with the version without the suffix , and the rt linker will select the appropriate version depending on the VFP  presence.
> 
> 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.
> 
> 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