From: Rongqing Li <rongqing.li@windriver.com>
To: Andre McCurdy <armccurdy@gmail.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [BUG REPORT] failed to build valgrind on qemuarm
Date: Wed, 20 Jan 2016 09:17:00 +0800 [thread overview]
Message-ID: <569EE00C.6070408@windriver.com> (raw)
In-Reply-To: <CAJ86T=WDHvsC2PKP5wKizrq_+Ri1Z6OTnJLhxsS4O1DoKpy=Bw@mail.gmail.com>
On 2016年01月20日 04:20, Andre McCurdy wrote:
> On Mon, Jan 18, 2016 at 11:27 PM, Rongqing Li <rongqing.li@windriver.com> wrote:
>>
>> 2: on qemuarma9
>>
>
> The problem seems to be that the machine doesn't support NEON and
> Valgrind 3.11 includes a new test case which uses embedded NEON
> instructions.
>
> We do already disable a few tests which don't build for all ARM
> machines (see "remove-arm-variant-specific.patch"), so maybe the
> "sh-mem-random" test should be disabled as well. I'll take a look.
>
> What DEFAULTTUNE does the qemuarma9 machine use?
>
DEFAULTTUNE="armv7at"
thanks
-Roy
>>
>> | 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
>>
>>
>> and the codes are below:
>>
>> 194 #elif defined(__linux__) && defined(__arm__) && !defined(__aarch64__)
>> 195 /* On arm32, many compilers generate a 64-bit float move
>> 196 using two 32 bit integer registers, which completely
>> 197 defeats this test. Hence force a 64-bit NEON load and
>> 198 store. I guess this will break the build on non-NEON
>> 199 capable targets. */
>> 200 __asm__ __volatile__ (
>> 201 "vld1.64 {d7},[%0] ; vst1.64 {d7},[%1] "
>> 202 : : "r"(arr+src), "r"(arr+dst) : "d7","memory"
>> 203 );
>> 204 #else
>>
>>
>> -Roy
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
Best Reagrds,
Roy | RongQing Li
next prev parent reply other threads:[~2016-01-20 1:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-19 7:27 [BUG REPORT] failed to build valgrind on qemuarm Rongqing Li
2016-01-19 7:47 ` Robert Yang
2016-01-19 7:50 ` Rongqing Li
2016-01-19 8:05 ` Robert Yang
2016-01-19 20:20 ` Andre McCurdy
2016-01-20 1:17 ` Rongqing Li [this message]
2016-01-19 21:00 ` Khem Raj
2016-01-19 21:38 ` Andre McCurdy
2016-01-19 23:23 ` Khem Raj
2016-01-20 1:45 ` Andre McCurdy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=569EE00C.6070408@windriver.com \
--to=rongqing.li@windriver.com \
--cc=armccurdy@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox