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

From: mmel@freebsd.org <mmel_at_FreeBSD.org>
Date: Sat, 04 Jan 2025 13:36:47 UTC

On 04.01.2025 14:18, Dimitry Andric wrote:
> 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?
> 
Reopened.

Michal