|
From: Wuweijia <wuw...@hu...> - 2017-09-12 04:41:40
Attachments:
testClang.cpp
clang4.0.rar
|
发件人: Wuweijia
发送时间: 2017年9月12日 12:34
收件人: 'val...@li...' <val...@li...>
抄送: Fanbohao <fan...@hu...>
主题: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.
Hello:
First, I build the program with clang 4.0 with 32 bit command param, but it run failed because there is unknown instruction;
Second , I build the program with clang 4.0 with 64 bit command param, and it run success.
Third, I build the same program with clang 3.8 with 32 bit command param, and I run success, there is no unknown instructions.
There is the error log:
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)
There is some point :
1: I build the arm application which is 32 bit , but it ran in the aarch64 server which is 64 bit;
The rar pack contain:
1: the compile command with clang 4.0:
2: the error log
3: the function main instruction (that compile with clang3.8 and clang4.0)
I had search the code. In the implementation, no matter clang3.8 or clang4.0 they all call __c11_atomic_compare_exchange_strong function to check the value. I think the source code maybe it is the same and fine.
If you need any more information , Please send e-mail to me and how to gather it step by step. I am waiting for reponse.
BR
Owen
|
|
From: John R. <jr...@bi...> - 2017-09-12 16:40:06
|
> 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)) {
=====
--
|
|
From: Wuweijia <wuw...@hu...> - 2017-09-13 03:20:21
Attachments:
vgtrace.rar
|
I think there is something different when I run the valgrind with your command .
It show me that valgrind die at :
Thread 1: status = VgTs_Runnable (lwpid 28961)
==28961== at 0x4039698: __dl_syscall (syscall.S:45)
==28961== by 0x40029A3: __dl__ZL24debuggerd_signal_handleriP7siginfoPv (debugger.cpp:295)
==28961== by 0x4044CD7: ??? (__restore.S:58)
Not before :
Die at:
Thread 1: status = VgTs_Runnable (lwpid 29198)
==29198== at 0x1089B6: compare_exchange_strong (atomic:943)
==29198== by 0x1089B6: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
==29198== by 0x1089B6: main (testClang.cpp:22)
I send to the vgtrace.rar
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...]
发送时间: 2017年9月13日 0:40
收件人: val...@li...
主题: Re: [Valgrind-users] 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.
> 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)) { =====
--
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: John R. <jr...@bi...> - 2017-09-13 23:23:14
|
Using the larger vgtrace.rar (871KB) from a message that was posted just a few minutes
before the smaller version (22.3KB), then the interesting part is near the end
***** line 358098
==== SB 4145 (evchecks 744961) [tid 1] 0x4002995 __dl__ZL24debuggerd_signal_handleriP7siginfoPv+584 /system_O/bin/linker+0x2995
------------------------ Front end ------------------------
(thumb) 0x4002994: mov r1, r0
------ IMark(0x4002994, 2, 1) ------
t0 = 0x0:I32
PUT(392) = t0
t1 = 0x1:I32
t2 = GET:I32(8)
PUT(12) = ITE(CmpNE32(t1,0x0:I32),t2,GET:I32(12))
PUT(68) = 0x4002997:I32
[[snip]]
(thumb) 0x40029A0: blx 0x4039678 (switch to ARM mode)
------ IMark(0x40029A0, 4, 1) ------
t13 = 0x0:I32
PUT(392) = t13
t14 = 0x1:I32
PUT(392) = t13
t15 = Shr32(t13,0x8:I8)
if (CmpNE32(t15,0x0:I32)) { PUT(68) = 0x40029A1:I32; exit-NoDecode }
PUT(392) = t13
if (Not1(32to1(t14))) { PUT(68) = 0x40029A5:I32; exit-Boring }
PUT(64) = 0x40029A5:I32
PUT(68) = 0x4039678:I32
PUT(68) = GET:I32(68); exit-Call
GuestBytes 4002995 16 46 40 F2 6B 10 52 46 5B 46 00 95 36 F0 6A EE 00 002ADA34
VexExpansionRatio 16 208 130 :10
--28961-- VALGRIND INTERNAL ERROR: Valgrind received a signal 4 (SIGILL) - exiting
--28961-- si_code=1; Faulting address: 0x0; sp: 0x831d9d94
*****
and the earlier translation for the subroutine at 0x4039678:
***** line 61104
==== SB 693 (evchecks 3967) [tid 1] 0x4039678 __dl_syscall /system_O/bin/linker+0x39678
------------------------ Front end ------------------------
(arm) 0x4039678: mov r12, r13 // no registers saved at entry
------ IMark(0x4039678, 4, 0) ------
t1 = GET:I32(60)
t0 = t1
t2 = t0
PUT(56) = t2
PUT(68) = 0x403967C:I32
(arm) 0x403967C: stmdb r13!, {0x00F0}
------ IMark(0x403967C, 4, 0) ------
t3 = GET:I32(60)
t4 = t3
PUT(60) = Sub32(t3,0x10:I32)
STle(Sub32(t4,0x4:I32)) = GET:I32(36)
STle(Sub32(t4,0x8:I32)) = GET:I32(32)
STle(Sub32(t4,0xC:I32)) = GET:I32(28)
STle(Sub32(t4,0x10:I32)) = GET:I32(24)
PUT(68) = 0x4039680:I32
[[snip]]
(arm) 0x4039690: ldmia r12, {0x0078}
------ IMark(0x4039690, 4, 0) ------
t17 = GET:I32(56)
t18 = t17
PUT(20) = LDle:I32(Add32(t18,0x0:I32))
PUT(24) = LDle:I32(Add32(t18,0x4:I32))
PUT(28) = LDle:I32(Add32(t18,0x8:I32))
PUT(32) = LDle:I32(Add32(t18,0xC:I32))
PUT(68) = 0x4039694:I32
(arm) 0x4039694: svc #0x00000000
------ IMark(0x4039694, 4, 0) ------
PUT(68) = 0x4039698:I32
PUT(68) = GET:I32(68); exit-Sys_syscall
(arm) 0x4039698: ldmia r13!, {0x00F0}
------ IMark(0x4039698, 4, 0) ------
t0 = GET:I32(60)
t1 = t0
PUT(24) = LDle:I32(Add32(t1,0x0:I32))
PUT(28) = LDle:I32(Add32(t1,0x4:I32))
PUT(32) = LDle:I32(Add32(t1,0x8:I32))
PUT(36) = LDle:I32(Add32(t1,0xC:I32))
PUT(60) = Add32(t0,0x10:I32)
PUT(68) = 0x403969C:I32
[[snip]]
(arm) 0x40396A0: bx{ls} r14 // conditional return; is taken to (thumb) 0x4008B8E [not shown]
------ IMark(0x40396A0, 4, 0) ------
t5 = armg_calculate_condition[mcx=0x9]{0x5815eb7c}(Or32(GET:I32(72),0x90:I32),GET:I32(76),GET:I32(80),GET:I32(84)):I32
if (Not1(32to1(t5))) { PUT(68) = 0x40396A4:I32; exit-Boring }
t6 = GET:I32(64)
PUT(68) = t6
PUT(68) = GET:I32(68); exit-Return
[[snip; note change to (thumb) mode]]
(thumb) 0x40423E6: add sp, #16 // THIS LOOKS VERY STRANGE; What is going on with the stack pointer?
------ IMark(0x40423E6, 2, 1) ------
t26 = GET:I32(392)
t27 = Shr32(t26,0x8:I8)
PUT(392) = t27
t28 = armg_calculate_condition[mcx=0x9]{0x5815eb7c}(Or32(GET:I32(72),Xor32(And32(t26,0xF0:I32),0xE0:I32)),GET:I32(76),GET:I32(80),GET:I32(84)):I32
t29 = ITE(CmpNE32(And32(t26,0xF0:I32),0x0:I32),t28,0x1:I32)
t30 = Xor32(And32(t26,0x1:I32),0x1:I32)
t31 = And32(t30,t29)
PUT(60) = ITE(CmpNE32(t29,0x0:I32),Add32(GET:I32(60),0x10:I32),GET:I32(60))
PUT(68) = 0x40423E9:I32
(thumb) 0x40423E8: ldmia r13!, {0x81F0} // unconditional return
------ IMark(0x40423E8, 4, 1) ------
t32 = 0x0:I32
PUT(392) = t32
t33 = 0x1:I32
PUT(392) = t32
t34 = Shr32(t32,0x8:I8)
if (CmpNE32(t34,0x0:I32)) { PUT(68) = 0x40423E9:I32; exit-NoDecode }
PUT(392) = t32
if (Not1(32to1(t33))) { PUT(68) = 0x40423ED:I32; exit-Boring }
t35 = GET:I32(60)
t36 = t35
PUT(24) = LDle:I32(Add32(t36,0x0:I32))
PUT(28) = LDle:I32(Add32(t36,0x4:I32))
PUT(32) = LDle:I32(Add32(t36,0x8:I32))
PUT(36) = LDle:I32(Add32(t36,0xC:I32))
PUT(40) = LDle:I32(Add32(t36,0x10:I32))
PUT(68) = LDle:I32(Add32(t36,0x14:I32))
PUT(60) = Add32(t35,0x18:I32)
PUT(68) = GET:I32(68)
PUT(68) = GET:I32(68); exit-Return
*****
I'm very unsure of what is happening.
--
|
|
From: Wuweijia <wuw...@hu...> - 2017-09-13 05:57:14
Attachments:
vgtrace_312.rar
|
Hi John:
I run the same application with valgrind 3.12 . I can the same stack when the application is down with your command line or not.
The same stack when the valgrind is down:
Thread 1: status = VgTs_Runnable (lwpid 29062)
==29062== at 0x1089B6: compare_exchange_strong (atomic:943)
==29062== by 0x1089B6: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376)
==29062== by 0x1089B6: main (testClang.cpp:22)
I think there maybe the bug in valgrind 3.13. Please check.
So I send you the vgtrace.txt that is created by valgrind 3.12. I think it maybe helpful to you and valgrind is right .
The Last vgtrace log is :
(thumb) 0x1089BC: ldr.w r14, [r13, +#128]
------ IMark(0x1089BC, 4, 1) ------
t9 = 0x0:I32
PUT(392) = t9
t10 = 0x1:I32
t11 = GET:I32(60)
t12 = Add32(t11,0x80:I32)
t13 = GET:I32(64)
t14 = GET:I32(64)
t15 = if-strict (CmpNE32(t10,0x0:I32)) Ident32(LDle(t12)) else t14
PUT(64) = t15
PUT(68) = 0x1089C1:I32
(thumb) 0x1089C0: ldrex r3, [r14, #+0]
------ IMark(0x1089C0, 4, 1) ------
t16 = 0x0:I32
PUT(392) = t16
t17 = 0x1:I32
if (Not1(32to1(t17))) { PUT(68) = 0x1089C5:I32; exit-Boring }
t18 = LDle-Linked(Add32(GET:I32(64),0x0:I32))
PUT(20) = t18
PUT(68) = 0x1089C5:I32
vex: external/valgrind/VEX/priv/guest_arm_toIR.c:13352 (decode_V8_instruction): Assertion `szBlg2 <= 3' failed.
BR
Owen
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...]
发送时间: 2017年9月13日 0:40
收件人: val...@li...
主题: Re: [Valgrind-users] 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para.
> 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)) { =====
--
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: John R. <jr...@bi...> - 2017-09-13 22:58:19
|
Wuweijia wrote: > I run the same application with valgrind 3.12 . I can the same stack when the application is down with your command line or not. > > The same stack when the valgrind is down: > Thread 1: status = VgTs_Runnable (lwpid 29062) > ==29062== at 0x1089B6: compare_exchange_strong (atomic:943) > ==29062== by 0x1089B6: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376) > ==29062== by 0x1089B6: main (testClang.cpp:22) > > I think there maybe the bug in valgrind 3.13. Please check. > > So I send you the vgtrace.txt that is created by valgrind 3.12. I think it maybe helpful to you and valgrind is right . > [[snip]] > vex: external/valgrind/VEX/priv/guest_arm_toIR.c:13352 (decode_V8_instruction): Assertion `szBlg2 <= 3' failed. Because valgrind-3.13 made changes to the code that handles atomic operations, then there is great reluctance to working on the previous version valgrind-3.12 except to compare and contrast with the current version valgrind-3.13. The traceback having the same address 0x1089B6 for all three subroutines, and the source location "testClang.cpp:22" suggests that you have a short test case that uses only a few shared libraries, or perhaps no shared library at all. If so, then please compress and attach the whole executable. That should be useful for analyzing. -- |
|
From: Wuweijia <wuw...@hu...> - 2017-09-14 05:48:37
|
Hi John I think the source "testClang.cpp:22" is cause. When I tested the testClang built by clang3.8 is okay, and I used the same shared libraries and linker . I meant the shared libraries and linker is the same , never change. BR Owen -----邮件原件----- 发件人: John Reiser [mailto:jr...@bi...] 发送时间: 2017年9月14日 6:58 收件人: val...@li... 主题: Re: [Valgrind-users] 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para. Wuweijia wrote: > I run the same application with valgrind 3.12 . I can the same stack when the application is down with your command line or not. > > The same stack when the valgrind is down: > Thread 1: status = VgTs_Runnable (lwpid 29062) > ==29062== at 0x1089B6: compare_exchange_strong (atomic:943) > ==29062== by 0x1089B6: atomic_compare_exchange_strong_explicit<unsigned int> (atomic:1376) > ==29062== by 0x1089B6: main (testClang.cpp:22) > > I think there maybe the bug in valgrind 3.13. Please check. > > So I send you the vgtrace.txt that is created by valgrind 3.12. I think it maybe helpful to you and valgrind is right . > [[snip]] > vex: external/valgrind/VEX/priv/guest_arm_toIR.c:13352 (decode_V8_instruction): Assertion `szBlg2 <= 3' failed. Because valgrind-3.13 made changes to the code that handles atomic operations, then there is great reluctance to working on the previous version valgrind-3.12 except to compare and contrast with the current version valgrind-3.13. The traceback having the same address 0x1089B6 for all three subroutines, and the source location "testClang.cpp:22" suggests that you have a short test case that uses only a few shared libraries, or perhaps no shared library at all. If so, then please compress and attach the whole executable. That should be useful for analyzing. -- ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Wuweijia <wuw...@hu...> - 2017-09-19 00:34:19
|
Hi John: I had sent you the shared object last week. Can you re-product the error now? BR Owen -----邮件原件----- 发件人: John Reiser [mailto:jr...@bi...] 发送时间: 2017年9月15日 5:32 收件人: Wuweijia <wuw...@hu...> 主题: Re: 答复: [Valgrind-users] 答复: 转发: [HELP] Is there any bug with the program built by the clang4.0 with thumbv7--linux-android command para. Hi Wuweijia, > Meanwhile, I will try using the *.so from my RaspberryPi3 running Fedora 27 (near beta). The libc.so.* for 32-bit ARM in neither Fedora 27 nor Xubuntu xenial has the symbol __stack_chk_guard which is required by testClang. Therefore I really do need the 32-bit android versions of the shared libraries. I'll see what I can find using just static dis-assembly ... -- John |