From owner-freebsd-arm@freebsd.org Thu Jan 26 18:25:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB96CCC338A for ; Thu, 26 Jan 2017 18:25:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-74.reflexion.net [208.70.210.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8FF786 for ; Thu, 26 Jan 2017 18:25:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5397 invoked from network); 26 Jan 2017 18:25:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Jan 2017 18:25:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Thu, 26 Jan 2017 13:25:03 -0500 (EST) Received: (qmail 31661 invoked from network); 26 Jan 2017 18:25:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jan 2017 18:25:03 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B22D3EC90A8; Thu, 26 Jan 2017 10:25:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: =mcpu=cortex-a7 buildlworld (for example) vs. __aeabi_uidiv use in ports from pkg From: Mark Millard In-Reply-To: Date: Thu, 26 Jan 2017 10:25:02 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <15C25780-588B-43EF-8DAC-000C301018BE@dsl-only.net> <1485446344.30533.72.camel@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 18:25:05 -0000 On 2017-Jan-26, at 8:15 AM, Michal Meloun 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