=mcpu=cortex-a7 buildlworld (for example) vs. __aeabi_uidiv use in ports from pkg

Michal Meloun melounmichal at gmail.com
Thu Jan 26 16:15:17 UTC 2017



On 26.01.2017 16:59, Ian Lepore wrote:
> On Thu, 2017-01-26 at 02:10 -0800, Mark Millard wrote:
>> If I buildworld buildkernel for arm.armv6 with the likes of:
>>
>> CFLAGS+= =mcpu=cortex-a7
>> CXXFLAGS+= =mcpu=cortex-a7
>> CPPFLAGS+= =mcpu=cortex-a7
>>
>> (say for targeting a bpim3 or rpi2) then what package
>> installs for that context tends to report:
>>
>> Undefined symbol "__aeabi_uidiv"
>>
>> In other words __aeabi_uidiv is only implemented
>> for armv6 buildworld, not if one explicitly targets
>> armv7. (armv7 has instruction support but that does
>> not make software built to support other processor
>> variants that are without instruction support also
>> work unless the routine is still provided.)
>>
>> Note: I normally build ports from source anyway
>> so this is just an FYI in case the lack of
>> __aeabi_uidiv was not deliberate.
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
> 
> I believe problems like this will not go away unless we stop trying to
> pretend that armv6 and armv7 are the same thing, and actually start
> treating armv7 as its own arch, especially for the purpose of packages
> and ports.
> 
> I've said/suggested this more than once, and every time it gets shot
> down by the people who actually understand what it takes to create a
> new arch (if I knew how to do it, I would have, long ago).  As near as
> I can tell, the argument against doing it is essentially "because it's
> hard".
> 
> So I guess... don't expect it to get better any time soon.
> 
> -- Ian
> 


The problems in more serious and is not related to armv6/armv7 but to
specific CPU type (Cortex-A8 have not hw divide instruction).

Currently, ARM libc (and few others libraries) accidentally exports some
__aeabi builtins originated by compiler_rt library. All functions
defined by DEFINE_AEABI_FUNCTION_ALIAS() macro have this problem.

The fix is (probably) not a hard, but all precomplied packages currently
depends on these symbols. I don't see any way how we can solve this
problem without braking all precompiled packages :(

Michal





More information about the freebsd-arm mailing list