Date: Thu, 26 Jan 2017 10:25:02 -0800 From: Mark Millard <markmi@dsl-only.net> To: mmel@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: =mcpu=cortex-a7 buildlworld (for example) vs. __aeabi_uidiv use in ports from pkg Message-ID: <D54B87B7-0EE6-4D44-A445-DF13524AD214@dsl-only.net> In-Reply-To: <ac8ae9ed-abcb-735d-40cd-b976684cb650@freebsd.org> References: <15C25780-588B-43EF-8DAC-000C301018BE@dsl-only.net> <1485446344.30533.72.camel@freebsd.org> <ac8ae9ed-abcb-735d-40cd-b976684cb650@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jan-26, at 8:15 AM, Michal Meloun <melounmichal at gmail.com> wrote: > 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). Agreed that it is only some armv7's that have the optional instructions in question. In one of my cases/contexts: CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features: Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7, PXN, LPAE, Coherent Walk Optional instructions: SDIV/UDIV, UMULL, SMULL, SIMD(ext) Sorry for my earlier poor wording on this that implied all armv7's would be this way. > 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 :( Providing a exported definition of each such routine even when the compiler is told of the optional instructions being present for the target of the buildworld would enable code that needs the routines. The compiler need not generate code to bind to those routines when it is told that the optional instructions will be available. It is the lack of generating the definitions for the likes of -mcpu=cortex-a7 that is the source of the incompatibility status from what I can tell: it ignores that some programs might target a smaller instruction set subset. Instead it requires that the optional instructions be used in all code by not providing the alterntiave. (I'm not claiming this is the only way to have compatibility.) > Michal === Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D54B87B7-0EE6-4D44-A445-DF13524AD214>