Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Apr 2012 14:04:44 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Mark Tinguely <marktinguely@gmail.com>
Cc:        arm@FreeBSD.org, Tim Kientzle <kientzle@FreeBSD.org>
Subject:   Re: Cross-buildworld works but not native build?
Message-ID:  <495386AF-37AB-450D-B78C-2A6282083587@bsdimp.com>
In-Reply-To: <CAP%2BM-_Ev1TE7JEmSRbVPg3HRwMfsPVyNyR92X5UONdxmGryuaQ@mail.gmail.com>
References:  <9AD7075B-B85D-40DB-84B7-FD630B858A30@freebsd.org> <CAP%2BM-_Ev1TE7JEmSRbVPg3HRwMfsPVyNyR92X5UONdxmGryuaQ@mail.gmail.com>

index | next in thread | previous in thread | raw e-mail


On Apr 27, 2012, at 1:51 PM, Mark Tinguely wrote:

> On Fri, Apr 27, 2012 at 1:48 AM, Tim Kientzle <kientzle@freebsd.org> wrote:
>> I've been working with the projects/armv6 tree and have encountered a very confusing situation.
>> 
>> On i386, this works:
>>  $ make TARGET_ARCH=arm TARGET_CPUTYPE=armv6 buildworld
>> 
>> If I take the resulting world and run it on arm, then the following fails (with the exact same source):
>>  $ make buildworld
>>  ….
>> cc  -O -pipe  -fpic -fvisibility=hidden -DVISIBILITY_HIDDEN -std=gnu99 -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=hidden -DVISIBILITY_HIDDEN -std=gnu99 -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=hidden -DVISIBILITY_HIDDEN -std=gnu99 -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)
>> 
>> 
>> 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).
>> 
>> 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.
>> 
>> 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 favor
> of the ldrex/strex operations.
> 
> 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=armv6 to the buildworld.

I'm hoping to fix issues like this in my armv6 patches.

help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?495386AF-37AB-450D-B78C-2A6282083587>