Re: [Valgrind-users] 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.

[John R. <jr...@bi...>]

>                  First, I build the program with clang 4.0 with 32 bit command  param,  but  it run failed because there is unknown instruction;

>                  disInstr(thumb): unhandled instruction: 0x450B 0xD104
> 
> ==24328== valgrind: Unrecognised instruction at address 0x1089c5.
> ==24328==    at 0x1089C4: compare_exchange_strong (atomic:943)
> ==24328==    by 0x1089C4: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
> ==24328==    by 0x1089C4: main (testClang.cpp:22)

It looks like there is some confusion because the program containing the supposed
unhandled instruction stream:
===== foo.S
	.short 0x450B,0xD104
=====
disassembles (in Thumb mode) to
     $ gcc -c foo.S
     $ gdb foo.o
     (gdb) x/x 0
       0x0: 0xd104450b
     (gdb) x/2i 1    # 1 for Thumb mode
       0x1:	cmp	r3, r1
       0x3:	bne.n	0xe
which valgrind should handle easily.

Please re-run valgrind on the failing program, using additional parameters to valgrind:
     --trace-notbelow=0  --trace-flags=10000000  2>vgtrace.txt

which gives an instruction-by-instruction trace.  The re-directed stderr file
vgtrace.txt will be large, possibly many megabytes.  Look near the end of the file
for the last line that contains "==== SB nnnnn " where nnnnn is a decimal number of
the block of instructions.  Please show us the output from there to the
end of the file, probably a couple dozen lines.  Quite possibly it contains
"ldrex r3, [lr]" or 0xE85E 0x3F00; but that should have been handled by the code in:
===== VEX/priv/guest_arm_toIR.c  l.22881
    /* ----------------- (T1) LDREX ----------------- */
    if (INSN0(15,4) == 0xE85 && INSN1(11,8) == BITS4(1,1,1,1)) {
=====

--