| Summary: | NEON is present but not detected by valgrind | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | notasas |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | crash | CC: | peter.maydell, pjfloyd |
| Priority: | NOR | ||
| Version First Reported In: | 3.6.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | output of 'valgrind -v -d -d /bin/false' | ||
> this code runs fine without valgrind: > a6310: ecb10b10 vldmia r1!, {d0-d7} > a6314: f29b8550 vshl.s16 q4, q0, #11 > a6318: f29ba552 vshl.s16 q5, q1, #11 Unfortunately "can I execute Neon instructions without them segfaulting?" is not a valid way to test for usable Neon on an ARM Linux platform. In particular, for A8 systems there is no way to turn off Neon without also disabling VFP. So if the kernel detects that it is running on early silicon with Neon bugs then Neon is not supported but the only way to tell userspace about this is via the aux vector and /proc/cpuinfo. I think Valgrind is behaving correctly here (detecting that the auxv is not advertising Neon) and the code you're trying to debug is incorrect (using Neon when it should not). (See the comments in bug 249775, where the auxv detection was put in; not doing this can result in weird intermittent segfaults later.) > I think Valgrind is
> behaving correctly here (detecting that the auxv is not advertising Neon) and
> the code you're trying to debug is incorrect (using Neon when it should not).
Well, NEON is working fine on this system and has been used in various ways. The real problem is that HWCAP_NEON flag has only appeared in 2.6.29 and I'm running 2.6.27 . I think valgrind should only check auxv NEON flag on kernels that actually can report it.
Of course I could update my kernel or backport auxv NEON reporting, but I'd prefer not to do so due to unrelated reasons.
I don't think we're going to fix issues for Linux 2.6.27 kernels. There doesn't seem to be any problem on recent kernels. |
Created attachment 57749 [details] output of 'valgrind -v -d -d /bin/false' Version: 3.6.0 OS: Linux Using Valgrind-3.6.1 ==1312== valgrind: Unrecognised instruction at address 0xa6314 (NEON vshl.s16). this code runs fine without valgrind: a6310: ecb10b10 vldmia r1!, {d0-d7} a6314: f29b8550 vshl.s16 q4, q0, #11 a6318: f29ba552 vshl.s16 q5, q1, #11 ... #uname -a Linux notaz-openpandora 2.6.27.46-omap1 #3 Sun Feb 20 19:28:22 EET 2011 armv7l GNU/Linux level2 log of 'valgrind /bin/false' attached, excerpt: #valgrind -v -d -d /bin/false --1325:1:debuglog DebugLog system started by Stage 1, level 2 logging requested ... --1325:1:main Get hardware capabilities ... --1325:1:machine ARMv7 VFP 1 VFP2 1 VFP3 1 NEON 1 --1325:1:main ... arch = ARM, hwcaps = ARMv7-vfp-neon ... --1325:1:initimg Setup client stack: size will be 8388608 --1325:2:initimg ARM has-neon from-auxv: NO --1325:2:initimg Client info: initial_IP=0x40007F0 initial_TOC=0x0 brk_base=0x14000 --1325:2:initimg Client info: initial_SP=0xBDA67CE0 max_stack_size=8388608 ... --1325-- Arch and hwcaps: ARM, ARMv7-vfp --1325-- Page sizes: currently 4096, max supported 4096 Reproducible: Always