|
From: David L. <dav...@sb...> - 2011-09-01 22:56:33
|
Michael Eskin wrote...
> but in all cases when running the tool even on very simple
> console mode "Hello World" applications, we're immediately
> getting a SIGILL crash on what appears to be the _start function
> in ucLibc before hitting any of our code.
...
> Here's the sort of thing we're running into, would appreciate
> any suggestions for what might be going on, we're completely
> stuck at this point...
>
>
> # valgrind -v ./diftDec dift_422cmode2_no_hdr.data output.dat -hdr -f 422
> Illegal instruction
>
I'm seeing the same symptom on a cortex a9 (see 1 below) which doesn't have the
SIMD (neon) nor VFP extensions. From the arm reference manual: "Advanced SIMD
and VFP are two optional extensions to ARMv7". My board doesnt have those
options, just the embedded FPU.
A debug session (see 2 below) shows that the problem for my board occurs in
coregrind/m_dispatch/dispatch-arm-linux.S:
#if defined(VGP_arm_linux)
.fpu vfp
....
VG_(run_innerloop):
push {r0, r1, r4, r5, r6, r7, r8, r9, fp, lr}
/* set FPSCR to vex-required default value */
mov r4, #0
fmxr fpscr, r4 <== illegal instruction here
The failure makes sense - the fpscr register is a SIMD/vfp extension register
and fmxr (now replaced by 'vmsr') is invalid without those extensions.
I experimented patching out the unimplemented opcodes, but as implied by the
comment 'vex-required default value' , there was an invariant failure (see 3
below) which I haven't tracked down yet.
Any clues/patches around the fpscr register usage for the armv7 be appreciated.
Detailed Output:
====================
1) Failure with the Cortex A9:
# valgrind /usr/bin/find
==753== Memcheck, a memory error detector
==753== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==753== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==753== Command: /usr/bin/find
==753==
==753==
==753== Process terminating with default action of signal 4 (SIGILL)
==753== Illegal opcode at address 0x38143358
==753== at 0x4000790: ??? (in /lib/ld-2.11.1.so)
==753==
==753== HEAP SUMMARY:
==753== in use at exit: 0 bytes in 0 blocks
==753== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==753==
==753== All heap blocks were freed -- no leaks are possible
==753==
==753== For counts of detected and suppressed errors, rerun with: -v
==753== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction
Comments:The application address (never actually emitted/executes) 0x4000790 is
at _start in ld.so
objdump -d ld-2.11.1.so
....
Disassembly of section .text:
00000790 <_start>:
790: f8df a068 ldr.w sl, [pc, #104] ; 7fc
<_dl_start_user+0x5e>
794: f8df 4068 ldr.w r4, [pc, #104] ; 800
<_dl_start_user+0x62>
798: 4668 mov r0, sp
79a: f000 f9fd bl b98 <_dl_start>
====================
2) Isolating failure in gdb session
term1> valgrind --wait-for-gdb=yes /usr/bin/find
term2>
handle SIGILL SIGSEGV nostop noprint >> .gdbinit
gdb /usr/lib/valgrind/memcheck-ppc32-linux 231
...
(gdb) c
Continuing.
Program received signal SIGILL, Illegal instruction.
vgPlain_run_innerloop () at m_dispatch/dispatch-arm-linux.S:61
61 m_dispatch/dispatch-arm-linux.S: No such file or directory.
in m_dispatch/dispatch-arm-linux.S
Comments: the location is the unimplemented opcode on the unimplemented
register.
====================
3) Failure with (probably naive) patched out vfp instructions at
dispatch-armn-linux.S:61...
# valgrind /usr/bin/find
==719== Memcheck, a memory error detector
==719== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==719== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==719== Command: /usr/bin/find
==719==
valgrind: m_scheduler/scheduler.c:1232 (vgPlain_scheduler): the 'impossible'
happened.
valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant
failure
==719== at 0x380574B4: report_and_quit (m_libcassert.c:209)
==719== by 0x38057763: vgPlain_assert_fail (m_libcassert.c:283)
==719== by 0x380BC773: vgPlain_scheduler (scheduler.c:1230)
==719== by 0x380D9A47: thread_wrapper (syswrap-linux.c:94)
==719== by 0x380D9BCB: run_a_thread_NORETURN (syswrap-linux.c:127)
==719== by 0xFFFFFFFF: ???
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==719== at 0x4000B98: _dl_start_final (rtld.c:363)
==719== by 0x400079D: ??? (in /lib/ld-2.11.1.so)
...
|
|
From: Julian S. <js...@ac...> - 2011-09-02 15:06:17
|
On Friday, September 02, 2011 12:56:25 AM David Lerner wrote: > > # valgrind -v ./diftDec dift_422cmode2_no_hdr.data output.dat -hdr -f > > 422 Illegal instruction > > I'm seeing the same symptom on a cortex a9 (see 1 below) which doesn't have > the SIMD (neon) nor VFP extensions. From the arm reference manual: > "Advanced SIMD and VFP are two optional extensions to ARMv7". My board > doesnt have those options, just the embedded FPU. So, a correct diagnosis -- the code has never been checked for a no-VFP no-NEON setup. I didn't think such things existed. Fixing it right will require configury hacking, and I don't have the h/w to check it with. > I experimented patching out the unimplemented opcodes, but as implied by > the comment 'vex-required default value' , there was an invariant failure > (see 3 below) which I haven't tracked down yet. You're on the right track. FWIW the x86-linux dispatcher has analogous ifdeffery which stops it SIGILLing when run on a non-SSE capable CPU. The "invariant failure" I think is a check, in the same file you edited, that the FPSCR values that are set up by the instructions you commented out, haven't changed. So if you can find the check bit, and comment that out, you'll be in with a chance. J |