|
From: Paulo C. P. de A. <pc...@ma...> - 2011-03-13 15:02:50
|
Hi, I just switched development of my language, and its jit generation based on gnu lightning on a x86_64 computer, and this happens when running jit generated code under valgrind. (other valgrind messages about bug report, etc) ==16208== Process terminating with default action of signal 4 (SIGILL) ==16208== Illegal opcode at address 0x9F14FD8 ==16208== at 0x9F14FD8: ??? ==16208== ==16208== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y (gdb) x/20i 0x0000000009f14fd8-20 0x9f14fc4: xor %rax,%rax 0x9f14fc7: rex.WB callq *%r13 0x9f14fca: nopw 0x0(%rax,%rax,1) 0x9f14fd0: mov 0x20(%rbx),%r10 0x9f14fd4: mov -0x28(%r10),%r10 => 0x9f14fd8: movslq 0x24(%r10),%r13d 0x9f14fdc: mov 0x28(%rbx),%r10 0x9f14fe0: lea 0x18(%r10),%rax 0x9f14fe4: mov %rax,0x28(%rbx) 0x9f14fe8: movabs $0x1,%rax 0x9f14ff2: mov %eax,(%r10) 0x9f14ff5: mov %r13,0x8(%r10) (gdb) x/4x 0x9f14fd8 0x9f14fd8: 0x45 0x63 0x6a 0x24 (gdb) x/4t 0x9f14fd8 0x9f14fd8: 01000101 01100011 01101010 00100100 $ rpm -q valgrind valgrind-3.6.1-1-mdv2011.0.x86_64 Sorry if this is an error in the code generation, but since it works, load and sign extends a 32 bit integer from memory to a 64 bit register, I believe it should be correct to some extent... In case it is useful, sources can be browsed at https://code.google.com/p/exl/source/browse/ and/or https://code.google.com/p/exl/source/browse/trunk/lib/ejit_x86-cpu.c Thanks, Paulo |
|
From: Tom H. <to...@co...> - 2011-03-13 15:52:12
|
On 13/03/11 14:29, Paulo César Pereira de Andrade wrote: > I just switched development of my language, and its jit generation > based on gnu lightning on a x86_64 computer, and this happens > when running jit generated code under valgrind. > > (other valgrind messages about bug report, etc) It would have been helpful if you had included them... As it is you have cut off some information that may have been important. I assume that among them was the text which you have included as the subject of this message? > ==16208== Process terminating with default action of signal 4 (SIGILL) > ==16208== Illegal opcode at address 0x9F14FD8 > ==16208== at 0x9F14FD8: ??? > ==16208== > ==16208== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y > > (gdb) x/20i 0x0000000009f14fd8-20 > 0x9f14fc4: xor %rax,%rax > 0x9f14fc7: rex.WB callq *%r13 > 0x9f14fca: nopw 0x0(%rax,%rax,1) > 0x9f14fd0: mov 0x20(%rbx),%r10 > 0x9f14fd4: mov -0x28(%r10),%r10 > => 0x9f14fd8: movslq 0x24(%r10),%r13d > 0x9f14fdc: mov 0x28(%rbx),%r10 > 0x9f14fe0: lea 0x18(%r10),%rax > 0x9f14fe4: mov %rax,0x28(%rbx) > 0x9f14fe8: movabs $0x1,%rax > 0x9f14ff2: mov %eax,(%r10) > 0x9f14ff5: mov %r13,0x8(%r10) > > (gdb) x/4x 0x9f14fd8 > 0x9f14fd8: 0x45 0x63 0x6a 0x24 That instruction should be handled by valgrind, but then you are looking at the output of valgrind there anyway, not the input, so it doesn't really tell us much. If you are getting an "unhandled instruction bytes" message from valgrind then you have almost certainly found a bug in valgrind and you should report it in the bug tracker. Make sure you include all the detail from at least that message onwards. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Paulo C. P. de A. <pc...@ma...> - 2011-03-13 17:22:58
|
Tom Hughes wrote: > On 13/03/11 14:29, Paulo César Pereira de Andrade wrote: > >> I just switched development of my language, and its jit generation >> based on gnu lightning on a x86_64 computer, and this happens >> when running jit generated code under valgrind. >> >> (other valgrind messages about bug report, etc) > > It would have been helpful if you had included them... As it is you have > cut off some information that may have been important. Reproducing the problem I see: vex amd64->IR: unhandled instruction bytes: 0x45 0x63 0x6A 0x24 0x4C 0x8B ==25936== valgrind: Unrecognised instruction at address 0x9f14670. ==25936== Your program just tried to execute an instruction that Valgrind ==25936== did not recognise. There are two possible reasons for this. ==25936== 1. Your program has a bug and erroneously jumped to a non-code ==25936== location. If you are running Memcheck and you just saw a ==25936== warning about a bad jump, it's probably your program's fault. ==25936== 2. The instruction is legitimate but Valgrind doesn't handle it, ==25936== i.e. it's Valgrind's fault. If you think this is the case or ==25936== you are not sure, please let us know and we'll try to fix it. ==25936== Either way, Valgrind will now raise a SIGILL signal which will ==25936== probably kill your program. ==25936== ==25936== Process terminating with default action of signal 4 (SIGILL) ==25936== Illegal opcode at address 0x9F14670 ==25936== at 0x9F14670: ??? ==25936== ==25936== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- But it was a bug of mine, as the %r13d was pointing to some error (sign extending a 32 bit register...), that the cpu just happens to apparently use some default behavior, as no test cases in my language were failing. I just traced it, and it is caused when loading a variable typed uint32_t (the language is dynamically typed but also supports static typing), so, when correcting it to use implicit zero extension, it is disassembled as: mov 0x24(%r10),%r13d i.e. 0x45 0x8b 0x6a 0x24 and valgrind works. >> (gdb) x/20i 0x0000000009f14fd8-20 >> 0x9f14fc4: xor %rax,%rax >> 0x9f14fc7: rex.WB callq *%r13 >> 0x9f14fca: nopw 0x0(%rax,%rax,1) >> 0x9f14fd0: mov 0x20(%rbx),%r10 >> 0x9f14fd4: mov -0x28(%r10),%r10 >> => 0x9f14fd8: movslq 0x24(%r10),%r13d >> 0x9f14fdc: mov 0x28(%rbx),%r10 >> 0x9f14fe0: lea 0x18(%r10),%rax >> 0x9f14fe4: mov %rax,0x28(%rbx) >> 0x9f14fe8: movabs $0x1,%rax >> 0x9f14ff2: mov %eax,(%r10) >> 0x9f14ff5: mov %r13,0x8(%r10) >> >> (gdb) x/4x 0x9f14fd8 >> 0x9f14fd8: 0x45 0x63 0x6a 0x24 > > That instruction should be handled by valgrind, but then you are looking > at the output of valgrind there anyway, not the input, so it doesn't > really tell us much. > > If you are getting an "unhandled instruction bytes" message from > valgrind then you have almost certainly found a bug in valgrind and you > should report it in the bug tracker. Make sure you include all the > detail from at least that message onwards. > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ Sorry for the noise, Paulo |