|
From: Serge S. <se...@lx...> - 2003-11-26 13:22:42
|
Hello All, Running a program with valgrind 2.0.0, I got the following problem: disInstr: unhandled instruction bytes: 0x66 0xAF 0xFC 0x9C |
|
From: folkert <fo...@va...> - 2023-04-18 15:12:47
|
Hi, I wrote a compiler for brainfuck to x86. The result is quite fast but I was curious if I could tune it even more. So I ran it in callgrind but this resulted in: folkert@snsv ~/Projects/bf-compiler (master)$ valgrind --tool=callgrind ./test ==77043== Callgrind, a call-graph generating cache profiler ==77043== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al. ==77043== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==77043== Command: ./test ==77043== ==77043== For interactive control, run 'callgrind_control -h'. vex amd64->IR: unhandled instruction bytes: 0xCD 0x80 0xC3 0x67 0x80 0x3E 0x0 0x74 0x5 0x83 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==77043== valgrind: Unrecognised instruction at address 0x40274e. ==77043== at 0x40274E: ??? (in /home/folkert/Projects/bf-compiler/test) ==77043== by 0x4020EE: ??? (in /home/folkert/Projects/bf-compiler/test) ==77043== Your program just tried to execute an instruction that Valgrind ==77043== did not recognise. There are two possible reasons for this. ==77043== 1. Your program has a bug and erroneously jumped to a non-code ==77043== location. If you are running Memcheck and you just saw a ==77043== warning about a bad jump, it's probably your program's fault. ==77043== 2. The instruction is legitimate but Valgrind doesn't handle it, ==77043== i.e. it's Valgrind's fault. If you think this is the case or ==77043== you are not sure, please let us know and we'll try to fix it. ==77043== Either way, Valgrind will now raise a SIGILL signal which will ==77043== probably kill your program. ==77043== ==77043== Process terminating with default action of signal 4 (SIGILL) ==77043== Illegal opcode at address 0x40274E ==77043== at 0x40274E: ??? (in /home/folkert/Projects/bf-compiler/test) ==77043== by 0x4020EE: ??? (in /home/folkert/Projects/bf-compiler/test) ==77043== ==77043== Events : Ir ==77043== Collected : 28836 ==77043== ==77043== I refs: 28,836 Illegal instruction (core dumped) If you're curious what is going wrong here, the source assembly and the x86 binary can be retrieved from https://vanheusden.com/permshare/callgrind-error.tar.xz Oh and if you would like to assemble the assembly yourself: as -g mandelbrot.s ld -g a.out -o test ./test then results in the mandelbrot-fractal. Regards, Folkert van Heusden |
|
From: folkert <fo...@va...> - 2023-04-18 15:46:41
|
> > I wrote a compiler for brainfuck to x86. > > The result is quite fast but I was curious if I could tune it even more. > > So I ran it in callgrind but this resulted in: ... > > ==77043== Process terminating with default action of signal 4 (SIGILL) > > ==77043== Illegal opcode at address 0x40274E > > ==77043== at 0x40274E: ??? (in /home/folkert/Projects/bf-compiler/test) > > ==77043== by 0x4020EE: ??? (in /home/folkert/Projects/bf-compiler/test) ... > > If you're curious what is going wrong here, the source assembly and the > > x86 binary can be retrieved from > > https://vanheusden.com/permshare/callgrind-error.tar.xz ... > Using an online disassembler, I found that the initial bytes decode to > int 0x80, which (under Linux) is a system call. Maybe you're making a > system call that valgrind does not recognize? One would need to know > register contents to go further with that. The 2 calls it does are: print_char: movb (%esi), %al movb %al, buffer movl $4, %eax movl $1, %ebx movl $buffer, %ecx movl $1, %edx int $0x80 ret exit: movl $1, %eax movl $0, %ebx int $0x80 When the program is ran directly from the command, it runs fine. So that's not the problem. |
|
From: Eliot M. <mo...@cs...> - 2023-04-18 15:50:31
|
On 4/18/2023 10:51 AM, folkert wrote: > Hi, > > I wrote a compiler for brainfuck to x86. > The result is quite fast but I was curious if I could tune it even more. > So I ran it in callgrind but this resulted in: > > folkert@snsv ~/Projects/bf-compiler (master)$ valgrind --tool=callgrind ./test > ==77043== Callgrind, a call-graph generating cache profiler > ==77043== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al. > ==77043== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info > ==77043== Command: ./test > ==77043== > ==77043== For interactive control, run 'callgrind_control -h'. > vex amd64->IR: unhandled instruction bytes: 0xCD 0x80 0xC3 0x67 0x80 0x3E 0x0 0x74 0x5 0x83 > vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 > vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE > vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 > ==77043== valgrind: Unrecognised instruction at address 0x40274e. > ==77043== at 0x40274E: ??? (in /home/folkert/Projects/bf-compiler/test) > ==77043== by 0x4020EE: ??? (in /home/folkert/Projects/bf-compiler/test) > ==77043== Your program just tried to execute an instruction that Valgrind > ==77043== did not recognise. There are two possible reasons for this. > ==77043== 1. Your program has a bug and erroneously jumped to a non-code > ==77043== location. If you are running Memcheck and you just saw a > ==77043== warning about a bad jump, it's probably your program's fault. > ==77043== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==77043== i.e. it's Valgrind's fault. If you think this is the case or > ==77043== you are not sure, please let us know and we'll try to fix it. > ==77043== Either way, Valgrind will now raise a SIGILL signal which will > ==77043== probably kill your program. > ==77043== > ==77043== Process terminating with default action of signal 4 (SIGILL) > ==77043== Illegal opcode at address 0x40274E > ==77043== at 0x40274E: ??? (in /home/folkert/Projects/bf-compiler/test) > ==77043== by 0x4020EE: ??? (in /home/folkert/Projects/bf-compiler/test) > ==77043== > ==77043== Events : Ir > ==77043== Collected : 28836 > ==77043== > ==77043== I refs: 28,836 > Illegal instruction (core dumped) > > If you're curious what is going wrong here, the source assembly and the > x86 binary can be retrieved from > https://vanheusden.com/permshare/callgrind-error.tar.xz > > Oh and if you would like to assemble the assembly yourself: > > as -g mandelbrot.s > ld -g a.out -o test > > ./test then results in the mandelbrot-fractal. Using an online disassembler, I found that the initial bytes decode to int 0x80, which (under Linux) is a system call. Maybe you're making a system call that valgrind does not recognize? One would need to know register contents to go further with that. Btw, naming a program "test" is not necessarily a wonderful idea if the current directory happens to be on your path, since "test" is a program often used by scripts. Cheers - Eliot Moss |
|
From: Floyd, P. <pj...@wa...> - 2023-04-18 16:34:19
|
On 18/04/2023 17:46, folkert wrote:
> The 2 calls it does are:
>
> print_char:
> movb (%esi), %al
> movb %al, buffer
> movl $4, %eax
> movl $1, %ebx
> movl $buffer, %ecx
> movl $1, %edx
> int $0x80
> ret
>
> exit:
> movl $1, %eax
> movl $0, %ebx
> int $0x80
Valgrind can't run just any executable binary. It has quite a lot of
hard coded limitations that correspont (mostly) to what compilers and
link editors will produce. So if you use assembler and use opcodes not
normally generated by compilers then it won't work.
The code that handles this is
case 0xCD: /* INT imm8 */
d64 = getUChar(delta); delta++;
/* Handle int $0xD2 (Solaris fasttrap syscalls). */
if (d64 == 0xD2) {
jmp_lit(dres, Ijk_Sys_int210, guest_RIP_bbstart + delta);
vassert(dres->whatNext == Dis_StopHere);
DIP("int $0xD2\n");
return delta;
}
goto decode_failure;
So int 0x80 results in a decode error.
Can you use syscall?
A+
Paul
|
|
From: folkert <fo...@va...> - 2023-04-19 09:46:48
|
> > The 2 calls it does are: > > > > print_char: > > movb (%esi), %al > > movb %al, buffer > > movl $4, %eax > > movl $1, %ebx > > movl $buffer, %ecx > > movl $1, %edx > > int $0x80 > > ret > > > > exit: > > movl $1, %eax > > movl $0, %ebx > > int $0x80 > > Valgrind can't run just any executable binary. It has quite a lot of hard > coded limitations that correspont (mostly) to what compilers and link > editors will produce. So if you use assembler and use opcodes not normally > generated by compilers then it won't work. ... > So int 0x80 results in a decode error. > > Can you use syscall? That solves the problem. Thanks! |
|
From: Mark W. <ma...@kl...> - 2023-04-20 20:16:42
|
On Wed, Apr 19, 2023 at 11:46:34AM +0200, folkert wrote: > > > The 2 calls it does are: > > > > > > print_char: > > > movb (%esi), %al > > > movb %al, buffer > > > movl $4, %eax > > > movl $1, %ebx > > > movl $buffer, %ecx > > > movl $1, %edx > > > int $0x80 > > > ret > > > > > > exit: > > > movl $1, %eax > > > movl $0, %ebx > > > int $0x80 > > > > Valgrind can't run just any executable binary. It has quite a lot of hard > > coded limitations that correspont (mostly) to what compilers and link > > editors will produce. So if you use assembler and use opcodes not normally > > generated by compilers then it won't work. > ... > > So int 0x80 results in a decode error. > > > > Can you use syscall? > > That solves the problem. Glad that resolved it.I also didn't know int 0x80 worked on amd64 as syscal (but not under valgrind). Note that this also https://bugs.kde.org/show_bug.cgi?id=342988 Cheers, Mark |
|
From: Nicholas N. <nj...@ca...> - 2003-11-27 09:27:44
Attachments:
scas.patch
|
On Wed, 26 Nov 2003, Serge Semashko wrote:
> Running a program with valgrind 2.0.0, I got the following problem:
> disInstr: unhandled instruction bytes: 0x66 0xAF 0xFC 0x9C
That looks like scas{l,w}. Try the attached patch, which was taken from
the CVS HEAD (or check out the CVS HEAD from the repository).
N |