From owner-freebsd-arm@FreeBSD.ORG Fri Apr 27 19:51:10 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 B15421065672; Fri, 27 Apr 2012 19:51:10 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF968FC0C; Fri, 27 Apr 2012 19:51:10 +0000 (UTC) Received: by dadz14 with SMTP id z14so4750896dad.17 for ; Fri, 27 Apr 2012 12:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zV3IlO5/l0xcoBIvm/Z5qoj4q00NbMgCxz4wvhfjoew=; b=HCb8fxFRPA8+JzTSOaUVq95eR1Znzn/68//bZOue8TNYao3XqeAJ6UPpLmv1QrZm7h JQyE+UgslQAN3qB6f+fRN6qHS6KACm3O+PO4q/5A3zSbv/9cX+vTrhmhUKtV5F2qjk7Z z4RC6sGJ1wLraphCbAKdROu5crB0wgEGYjZQZg65EcFVPmMQ+iqvhw5q3APNgIdZKQZq MnZqhEpJjkZCwR37lzsCc1Io1L77qJ/g7DAf+PSFT3bhV7OC9kaTUHi3DJz8n/KQcoMD fqEfOmhpYqtce7ZZxvaotUZaZw/IdvKmyWg5o7Cjs8gaOTCCdfta7o5zyO+cmGG0kznx 8WYA== MIME-Version: 1.0 Received: by 10.68.134.8 with SMTP id pg8mr88701pbb.152.1335556264810; Fri, 27 Apr 2012 12:51:04 -0700 (PDT) Received: by 10.68.49.227 with HTTP; Fri, 27 Apr 2012 12:51:04 -0700 (PDT) In-Reply-To: <9AD7075B-B85D-40DB-84B7-FD630B858A30@freebsd.org> References: <9AD7075B-B85D-40DB-84B7-FD630B858A30@freebsd.org> Date: Fri, 27 Apr 2012 14:51:04 -0500 Message-ID: From: Mark Tinguely To: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org 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 19:51:10 -0000 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 ver= y confusing situation. > > On i386, this works: > =A0$ make TARGET_ARCH=3Darm TARGET_CPUTYPE=3Darmv6 buildworld > > If I take the resulting world and run it on arm, then the following fails= (with the exact same source): > =A0$ make buildworld > =A0=85. > cc =A0-O -pipe =A0-fpic -fvisibility=3Dhidden -DVISIBILITY_HIDDEN -std=3D= gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wn= o-pointer-sign -c /usr/src/lib/libcompiler_rt/../../contrib/compiler-rt/lib= /umoddi3.c -o umoddi3.o > cc =A0-O -pipe =A0-fpic -fvisibility=3Dhidden -DVISIBILITY_HIDDEN -std=3D= gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wn= o-pointer-sign -c /usr/src/lib/libcompiler_rt/../../contrib/compiler-rt/lib= /umodti3.c -o umodti3.o > cc =A0-O -pipe =A0-fpic -fvisibility=3Dhidden -DVISIBILITY_HIDDEN -std=3D= gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wn= o-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, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 from /usr/src/lib/libcompiler_rt/__sync_f= etch_and_add_4.c:6: > /usr/obj/usr/src/tmp/usr/include/machine/atomic.h: In function 'atomic_cm= pset_32': > /usr/obj/usr/src/tmp/usr/include/machine/atomic.h:491: error: 'ARM_RAS_ST= ART' undeclared (first use in this function) > /usr/obj/usr/src/tmp/usr/include/machine/atomic.h:491: error: (Each undec= lared identifier is reported only once > /usr/obj/usr/src/tmp/usr/include/machine/atomic.h:491: error: for each fu= nction it appears in.) > /usr/obj/usr/src/tmp/usr/include/machine/atomic.h: In function 'atomic_ad= d_32': > /usr/obj/usr/src/tmp/usr/include/machine/atomic.h:516: error: 'ARM_RAS_ST= ART' undeclared (first use in this function) > > > Looking at the source, ARM_RAS_START really does seem to be undeclared (i= t's declared in sysarch.h, but atomic.h only includes sysarch.h for kernel = builds). > > So it looks to me like the cross-buildworld should fail also. =A0In any c= ase, it's not clear why the two aren't behaving the same way. > > Tim > Looks like ARM_ARCH_6 or ARM_ARCH_7A is not defined. ARM_RAS_START/ARM_RAS_END has been removed out of the the ARMv6/ARMv7 in fa= vor of the ldrex/strex operations. Also the ARM_TP_ADDRESS is not used nor mapped and uses a built-in processor thread register. --Mark.