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 ([email protected]) > http://compton.nu/ Sorry for the noise, Paulo ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
