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

On Mon, 2014-05-19 at 00:08 +0400, Boris Samorodov wrote:
> 18.05.2014 20:38, Ian Lepore пишет:
> > 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.
> 
> You are right, that didn't help. The build has faild with the same
> error.
> 
> > 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.
> 
> Well, the thing is I don't have any 10-stable...
> 
> > [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.
> 
> It's definitely not my day -- crochet build failed with:
> -----
> --- all_subdir_libllvmarmcodegen ---
> /usr/src/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15:
> error: no member named
>  'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean
> 'VST1d64TPseudoWB_fixed'?
>     case ARM::VLD1d64TPseudoWB_fixed:
>          ~~~~~^~~~~~~~~~~~~~~~~~~~~~
>               VST1d64TPseudoWB_fixed
> ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' declared here
>     VST1d64TPseudoWB_fixed      = 1953,
>     ^
> /usr/src/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15:
> error: no member named
>  'VLD1d64QPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean
> 'VST1d64QPseudoWB_fixed'?
>     case ARM::VLD1d64QPseudoWB_fixed:
>          ~~~~~^~~~~~~~~~~~~~~~~~~~~~
>               VST1d64QPseudoWB_fixed
> ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' declared here
>     VST1d64QPseudoWB_fixed      = 1947,
> -----

I've seen others report this error recently, and it was caused by an
update to clang.  There's a dependency glitch so that some header files
don't get regenerated correctly; I think that has been fixed, but to get
the fix in place you have to clean out obj/arm.armv6 and build fresh.

-- Ian