Hi folks, I am trying to use arm gcc 5.3 to build part of android AOSP and hit following issue with arm gcc 5.3:
The gcc cmd line is like: /opt/work/acadine/mem_shrink/B2G-v2.5/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-5.3-linaro/bin/arm-linux-androideabi-g++ -I external/libcxx/include -I system/core/libbacktrace -I out/target/product/linaro_arm/obj/SHARED_LIBRARIES/libbacktrace_intermediates -I out/target/product/linaro_arm/gen/SHARED_LIBRARIES/libbacktrace_intermediates -I libnativehelper/include/nativehelper -I system/core/base/include -I external/libunwind/include -isystem system/core/include -isystem system/media/audio/include -isystem hardware/libhardware/include -isystem hardware/libhardware_legacy/include -isystem hardware/ril/include -isystem libnativehelper/include -isystem frameworks/native/include -isystem frameworks/native/opengl/include -isystem frameworks/av/include -isystem frameworks/base/include -isystem out/target/product/linaro_arm/obj/include -isystem bionic/libc/arch-arm/include -isystem bionic/libc/include -isystem bionic/libc/kernel/uapi -isystem bionic/libc/kernel/uapi/asm-arm -isystem bionic/libm/include -isystem bionic/libm/include/arm -c -fno-exceptions -Wno-multichar -msoft-float -ffunction-sections -fdata-sections -funwind-tables -fstack-protector -Wa,--noexecstack -Werror=format-security -D_FORTIFY_SOURCE=2 -fno-short-enums -no-canonical-prefixes -fno-canonical-system-headers -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -include build/core/combo/include/arch/linux-arm/AndroidConfig.h -I build/core/combo/include/arch/linux-arm/ -Wno-psabi -mthumb-interwork -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -DNDEBUG -g -Wstrict-aliasing=2 -fgcse-after-reload -frerun-cse-after-loop -frename-registers -DNDEBUG -UDEBUG -fvisibility-inlines-hidden -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Wsign-promo -std=gnu++11 -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -DNDEBUG -UDEBUG -mthumb -Os -fomit-frame-pointer -fno-strict-aliasing -fno-rtti -Wall -Werror -fPIC -D_USING_LIBCXX -std=gnu++11 -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -MD -MF out/target/product/linaro_arm/obj/SHARED_LIBRARIES/libbacktrace_intermediates/UnwindCurrent.d -o out/target/product/linaro_arm/obj/SHARED_LIBRARIES/libbacktrace_intermediates/UnwindCurrent.o system/core/libbacktrace/UnwindCurrent.cpp
And I got error: /tmp/ccZ40ViQ.s: Assembler messages: /tmp/ccZ40ViQ.s:1752: Error: selected processor does not support ARM mode `cbnz r6,.L91' /tmp/ccZ40ViQ.s:1758: Error: selected processor does not support ARM mode `cbnz r0,.L92' /tmp/ccZ40ViQ.s:1763: Error: selected processor does not support ARM mode `cbz r1,.L107' /tmp/ccZ40ViQ.s:1941: Error: selected processor does not support ARM mode `cbz r6,.L100'
But if I use the arm gcc 4.9, there is no any build issue.
the "-dumpspecs" output of gcc 5.3 was attached. Thanks.
Regards Yin, Fengwei
On Wed, Mar 30, 2016 at 5:18 PM, yfw fengwei.yin@linaro.org wrote:
/tmp/ccZ40ViQ.s:1752: Error: selected processor does not support ARM mode `cbnz r6,.L91'
Looking at gcc, I see that in thumb2 mode, for a conditional branch, it will emit cbnz if the target is in range and it is using a thumb2 low register, otherwise it emits cmp/bne. So this perhaps could be a bug with the compiler calculating instruction sizes wrong, and hence getting the range calculation from the branch to the target label wrong. We would need a reproducible testcase to investigate. The easiest way to do this if to add --save-temps to the g++ command, and then send us the UnwindCurrent.ii file. We also need the g++ command line, but you already gave us that. Otherwise, we have to figure out how to build AOSP with gcc-5.3. I'm not sure if anyone on the toolchain team is doing that regularly.
There could also be something else going wrong here, e.g. the code could have extended asms using cbnz which aren't valid in thumb2 mode, the assembler could be somehow in thumb1 mode, etc, but these seem less likely in this case.
Jim
linaro-toolchain@lists.linaro.org