> # valgrind -v -d /bin/true
> --2222:1: main Welcome to Valgrind version 3.11.0 debug logging
Thank you for using the current version of valgrind.
> --2222:1: main ...
> /mnt/nfs/gateway-hi3535/sdk/modules/valgrind-3.11.0/inst/bin/valgrind
> --2222:1: main Get hardware capabilities ...
> --2222:1: machine ARMv7 VFP 0 VFP2 0 VFP3 0 NEON 0
> --2222:1: cache Could not autodetect cache info
> --2222:1: main ... arch = ARM, hwcaps = ARMv7
So valgrind is running on an ARM machine.
> ==2222== Process terminating with default action of signal 4 (SIGILL)
> ==2222== Illegal opcode at address 0x380869FC
> ==2222== at 0x4000790: ??? (in /lib/ld-2.11.1.so)
> # cat /proc/cpuinfo
### Yes, it is an ARM machine:
> Processor : ARMv7 Processor rev 1 (v7l)
> processor : 0
> BogoMIPS : 1987.37
>
> processor : 1
> BogoMIPS : 1993.93
>
> Features : swp half thumb fastmult edsp tls
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x4
> CPU part : 0xc09
> CPU revision : 1
>
> Hardware : hi3535
> Revision : 0000
> Serial : 0000000000000000
>
>
Here the shell prompt changes from "# " above, to "$ " below.
You change from running on the ARM machine to running on a x86 box.
The disassembly "adc %cl,-0x1f(%edx)" proves that gdb is an x86 gdb
because "%cl" and "%edx" are x86 register names.
Instead: please use a gdb for ARM to look at the instruction at address
0x380869FC
in the ARM module memcheck-arm-linux, which probably resides in the filesystem
near
/mnt/nfs/gateway-hi3535/sdk/modules/valgrind-3.11.0/inst/bin/valgrind
> $ gdb memcheck-arm-linux
> GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
> (gdb) x/x 0x380869FC
> 0x380869fc <vgPlain_disp_run_translations+8>: 0xeee14a10
That's an ARM opcode. My RaspberryPi says it is "vmsr fpscr,r4"
which is attempting to set some modes in the floating point hardware
(such as precision, rounding mode, flush-to-zero for denormals,
NaN control, etc.) from bits in general register r4.
However, valgrind does not allow that because valgrind assumes
exactly one configuration for floating point, which cannot be changed.
You must inspect the source code (and the value in r4) to find out
what the code is trying to do. If it's anything fancy, then it
won't work under valgrind. If it is what valgrind assumes,
then just comment out the instruction, or replace it with a nop.
You can do this in a quick-and-dirty way by overwriting with
0xe1a00000 which is the nop "mov r0,r0".
> (gdb) x/i 0x380869FC
> 0x380869fc <vgPlain_disp_run_translations+8>: adc %cl,-0x1f(%edx)
That is an x86 disassembly.
> (gdb) q
>
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
