[OE-core] [BUG REPORT] failed to build valgrind on qemuarm

Khem Raj raj.khem at gmail.com
Tue Jan 19 23:23:08 UTC 2016


> On Jan 19, 2016, at 1:38 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
> 
> On Tue, Jan 19, 2016 at 1:00 PM, Khem Raj <raj.khem at gmail.com> wrote:
>> 
>>> On Jan 18, 2016, at 11:27 PM, Rongqing Li <rongqing.li at windriver.com> wrote:
>>> 
>>> 2: on qemuarma9
>>> 
>>> | arm-wrs-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp  -marm -mthumb-interwork --sysroot=/work/wr/buildarea/arm/bitbake_build/tmp/sysroots/qemuarma9 -DHAVE_CONFIG_H -I. -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/memcheck/tests -I../.. -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0 -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/include -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/coregrind -I../../include -I/work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/VEX/pub -I../../VEX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1   -Winline -Wall -Wshadow -Wno-long-long -g -fno-stack-protector    -O2 -pipe -g  -fno-omit-frame-pointer -fvisibility=default -O0 -c -o sh-mem-random.o /work/wr/buildarea/arm/bitbake_build/tmp/work/armv7a-vfp-wrs-linux-gnueabi/valgrind/3.11.0-r0/valgrind-3.11.0/memcheck/tests/sh-mem-random.c
>>> | {standard input}: Assembler messages:
>>> | {standard input}:1107: Error: selected processor does not support ARM mode `vld1.64 {d7},[r3]'
>>> | {standard input}:1107: Error: selected processor does not support ARM mode `vst1.64 {d7},[r2]'
>>> | Makefile:2467: recipe for target 'sh-mem-random.o’ failed
>> 
>> 
>> So you disable neon but do not choose a particular implementation which allows so. e.g. you should have -mtune=cortex-a9 which allows neon to be optional
>> but thats probably just the semantic thing. Below code should check for __ARM_NEON__ internal define being set as well before resorting to use neon instructions.
> 
> It's a test app which is failing, so I think we have 3 solutions:
> 
> 1) Disable tests which don't build for all supported targets (the
> traditional OE approach). See:
> 
>  http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/valgrind/valgrind/remove-arm-variant-specific.patch
> 
> 2) Tweak CFLAGS so that the test always compiles but fails at run-time
> on non-neon targets.
> 
> 3) Tweak test code so that it avoids NEON instructions on non-neon
> targets (risk then is that the run-time test will appear to pass on
> non-neon targets when it should actually fail).
> 
> 
> Any preference?

option 3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160119/3a5812d3/attachment-0002.sig>


More information about the Openembedded-core mailing list