Re: [arm cross-compiling, clang] Error: selected processor does not support `ldrexd r2,r3,[r1]'

From: Ian Lepore <ian_at_FreeBSD.org>
Date: Sun, 18 May 2014 10:38:05 -0600
On Sun, 2014-05-18 at 20:09 +0400, Boris Samorodov wrote:
> 18.05.2014 19:48, Boris Samorodov пишет:
> > Hi All,
> > 
> > The system:
> > -----
> > % uname -a
> > FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #92 r266163: Thu
> > May 15 23:22:26 SAMT 2014
> > bsam_at_bb052.bsnet:/usr/obj/usr/src/sys/BB64X  amd64
> > 
> > % clang --version
> > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> > Target: x86_64-unknown-freebsd11.0
> > Thread model: posix
> > -----
> > 
> > While cross-compiling (sources r266396) I get:
> > -----
> > % make -C /usr/src ARCH=arm TARGET_ARCH=armv6 buildworld
> 
> Hm, at https://wiki.freebsd.org/EmbeddedHandbook one more option
> is listed: "TARGET_CPUTYPE=armv6". Trying this.
> 
> > [...]
> > ===> lib/clang/liblldbAPI (all)
> > c++   -O -pipe
> > -I/usr/src/lib/clang/liblldbAPI/../../../contrib/llvm/tools/lldb/include
> > -I/usr/src/lib/clang/liblldbAPI/../../
> > ../contrib/llvm/tools/lldb/source
> > -I/usr/src/lib/clang/liblldbAPI/../../../contrib/llvm/include
> > -I/usr/src/lib/clang/liblldbAP
> > I/../../../contrib/llvm/tools/clang/include
> > -I/usr/src/lib/clang/liblldbAPI/../../../contrib/llvm/tools/lldb/source/API
> > -I. -I
> > /usr/src/lib/clang/liblldbAPI/../../../contrib/llvm/../../lib/clang/include
> > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MA
> > CROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing
> > -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIP
> > LE=\"armv6-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
> > -Qunused-arguments -std=c++11 -DLLDB_DISABLE_PYTHON -fno-exceptions -f
> > no-rtti -Wno-c++11-extensions -c
> > /usr/src/lib/clang/liblldbAPI/../../../contrib/llvm/tools/lldb/source/API/SBAddress.cpp
> > -o SB
> > Address.o
> > /tmp/SBAddress-9939f3.s: Assembler messages:
> > /tmp/SBAddress-9939f3.s:92: Error: selected processor does not support
> > `ldrexd r2,r3,[r1]'
> > /tmp/SBAddress-9939f3.s:141: Error: selected processor does not support
> > `ldrexd r2,r3,[r0]'
> > /tmp/SBAddress-9939f3.s:311: Error: selected processor does not support
> > `ldrexd r8,r9,[r0]'
> > /tmp/SBAddress-9939f3.s:312: Error: selected processor does not support
> > `strexd r1,r2,r3,[r0]'
> > /tmp/SBAddress-9939f3.s:320: Error: selected processor does not support
> > `ldrexd r2,r3,[r0]'
> > /tmp/SBAddress-9939f3.s:325: Error: selected processor does not support
> > `ldrexd r2,r3,[r0]'
> > /tmp/SBAddress-9939f3.s:329: Error: selected processor does not support
> > `ldrexd r2,r3,[r0]'
> > /tmp/SBAddress-9939f3.s:330: Error: selected processor does not support
> > `strexd r2,r4,r5,[r0]'
> > /tmp/SBAddress-9939f3.s:379: Error: selected processor does not support
> > `ldrexd r0,r1,[r0]'
> > /tmp/SBAddress-9939f3.s:507: Error: selected processor does not support
> > `ldrexd r2,r3,[r0]'
> > /tmp/SBAddress-9939f3.s:511: Error: selected processor does not support
> > `ldrexd r2,r3,[r0]'
> > /tmp/SBAddress-9939f3.s:512: Error: selected processor does not support
> > `strexd r2,r8,r9,[r0]'
> > /tmp/SBAddress-9939f3.s:665: Error: selected processor does not support
> > `ldrexd r4,r5,[r1]'
> > /tmp/SBAddress-9939f3.s:671: Error: selected processor does not support
> > `ldrexd r6,r7,[r1]'
> > /tmp/SBAddress-9939f3.s:678: Error: selected processor does not support
> > `ldrexd r2,r3,[r1]'
> > /tmp/SBAddress-9939f3.s:679: Error: selected processor does not support
> > `strexd r2,r6,r7,[r1]'
> > /tmp/SBAddress-9939f3.s:739: Error: selected processor does not support
> > `ldrexdne r0,r1,[r0]'
> > c++: error: assembler command failed with exit code 1 (use -v to see
> > invocation)
> > *** Error code 1
> > 
> > Stop.
> > make[6]: stopped in /usr/src/lib/clang/liblldbAPI
> > *** Error code 1
> > -----

While I don't think it should affect this problem, "ARCH=arm" isn't
needed.  If anything it would be TARGET=arm, but that's implied by the
TARGET_ARCH=armv6.

I suspect the problems you're seeing are more fallout from all the
recent WITH/WITHOUT build system changes.  I've been so focused on doing
arm MFCs for the past week I haven't tried to build -current for a few
days.

Since 10-stable is now in sync [1] with -current for arm stuff, but
doesn't have all the recent build system changes, that might be a
workable alternative for you for now... just build 10-stable instead of
-current.

[1] mostly -- I'm still finding a few misc changesets that I missed on
the first pass, and build/run testing of 10-stable on arm is just
beginning.

-- Ian
Received on Sun May 18 2014 - 14:38:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:49 UTC