From owner-freebsd-arm@FreeBSD.ORG Fri Apr 27 20:09:41 2012 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1824E106566B; Fri, 27 Apr 2012 20:09:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BAF198FC0C; Fri, 27 Apr 2012 20:09:40 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q3RK4ivM013804 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2012 14:04:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Fri, 27 Apr 2012 14:04:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <495386AF-37AB-450D-B78C-2A6282083587@bsdimp.com> References: <9AD7075B-B85D-40DB-84B7-FD630B858A30@freebsd.org> To: Mark Tinguely X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 27 Apr 2012 14:04:52 -0600 (MDT) Cc: arm@FreeBSD.org, Tim Kientzle Subject: Re: Cross-buildworld works but not native build? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 20:09:41 -0000 On Apr 27, 2012, at 1:51 PM, Mark Tinguely wrote: > On Fri, Apr 27, 2012 at 1:48 AM, Tim Kientzle = wrote: >> I've been working with the projects/armv6 tree and have encountered a = very confusing situation. >>=20 >> On i386, this works: >> $ make TARGET_ARCH=3Darm TARGET_CPUTYPE=3Darmv6 buildworld >>=20 >> If I take the resulting world and run it on arm, then the following = fails (with the exact same source): >> $ make buildworld >> =85. >> cc -O -pipe -fpic -fvisibility=3Dhidden -DVISIBILITY_HIDDEN = -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k = -Wno-uninitialized -Wno-pointer-sign -c = /usr/src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/umoddi3.c -o = umoddi3.o >> cc -O -pipe -fpic -fvisibility=3Dhidden -DVISIBILITY_HIDDEN = -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k = -Wno-uninitialized -Wno-pointer-sign -c = /usr/src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/umodti3.c -o = umodti3.o >> cc -O -pipe -fpic -fvisibility=3Dhidden -DVISIBILITY_HIDDEN = -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k = -Wno-uninitialized -Wno-pointer-sign -c = /usr/src/lib/libcompiler_rt/__sync_fetch_and_add_4.c -o = __sync_fetch_and_add_4.o >> In file included from = /usr/src/lib/libcompiler_rt/__sync_fetch_and_op_n.h:31, >> from = /usr/src/lib/libcompiler_rt/__sync_fetch_and_add_4.c:6: >> /usr/obj/usr/src/tmp/usr/include/machine/atomic.h: In function = 'atomic_cmpset_32': >> /usr/obj/usr/src/tmp/usr/include/machine/atomic.h:491: error: = 'ARM_RAS_START' undeclared (first use in this function) >> /usr/obj/usr/src/tmp/usr/include/machine/atomic.h:491: error: (Each = undeclared identifier is reported only once >> /usr/obj/usr/src/tmp/usr/include/machine/atomic.h:491: error: for = each function it appears in.) >> /usr/obj/usr/src/tmp/usr/include/machine/atomic.h: In function = 'atomic_add_32': >> /usr/obj/usr/src/tmp/usr/include/machine/atomic.h:516: error: = 'ARM_RAS_START' undeclared (first use in this function) >>=20 >>=20 >> Looking at the source, ARM_RAS_START really does seem to be = undeclared (it's declared in sysarch.h, but atomic.h only includes = sysarch.h for kernel builds). >>=20 >> So it looks to me like the cross-buildworld should fail also. In any = case, it's not clear why the two aren't behaving the same way. >>=20 >> Tim >>=20 >=20 > Looks like ARM_ARCH_6 or ARM_ARCH_7A is not defined. >=20 > ARM_RAS_START/ARM_RAS_END has been removed out of the the ARMv6/ARMv7 = in favor > of the ldrex/strex operations. >=20 > Also the ARM_TP_ADDRESS is not used nor mapped and uses a built-in > processor thread > register. I think it would work in the current tree if you added = TARGET_CPUTYPE=3Darmv6 to the buildworld. I'm hoping to fix issues like this in my armv6 patches.=