|
From: Eduardo M. <ea...@us...> - 2006-02-08 17:00:59
|
I am getting the following problem:
In a IA32 machine, write and compile the following test program:
~~~~~
#include <stdlib.h>
int main(int argc, char **argv)
{
asm ("int $129");
exit(0);
}
~~~~~
Run the above program in valgrind-3.1.0 with tool none, valgrind has error
outputs: vex x86->IR: unhandled instruction bytes: 0xCD 0x81 0x83 0xEC
~~~~~
#:~/valgrind-3.1.0/none/tests/x86 # valgrind --tool=3Dnone ./int
=3D=3D3752=3D=3D Nulgrind, a binary JIT-compiler.
=3D=3D3752=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Nicholas Nether=
cote.
=3D=3D3752=3D=3D Using LibVEX rev 1471, a library for dynamic binary transl=
ation.
=3D=3D3752=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
=3D=3D3752=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation fra=
mework.
=3D=3D3752=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward e=
t al.
=3D=3D3752=3D=3D For more details, rerun with: -v
=3D=3D3752=3D=3D
vex x86->IR: unhandled instruction bytes: 0xCD 0x81 0x83 0xEC
=3D=3D3752=3D=3D Your program just tried to execute an instruction that Val=
grind
=3D=3D3752=3D=3D did not recognise. There are two possible reasons for thi=
s.
=3D=3D3752=3D=3D 1. Your program has a bug and erroneously jumped to a non-=
code
=3D=3D3752=3D=3D location. If you are running Memcheck and you just saw=
a
=3D=3D3752=3D=3D warning about a bad jump, it's probably your program's =
fault.
=3D=3D3752=3D=3D 2. The instruction is legitimate but Valgrind doesn't hand=
le it,
=3D=3D3752=3D=3D i.e. it's Valgrind's fault. If you think this is the c=
ase or
=3D=3D3752=3D=3D you are not sure, please let us know.
=3D=3D3752=3D=3D Either way, Valgrind will now raise a SIGILL signal which =
will
=3D=3D3752=3D=3D probably kill your program.
=3D=3D3752=3D=3D
=3D=3D3752=3D=3D Process terminating with default action of signal 4 (SIGIL=
L)
=3D=3D3752=3D=3D Illegal opcode at address 0x80483A8
=3D=3D3752=3D=3D at 0x80483A8: main (int.c:5)
=3D=3D3752=3D=3D
Illegal instruction
~~~~~
Expected results from valgrind:=20
Process terminating with default action of signal 11 (SIGSEGV)
GPF (Pointer out of bounds?)
at 0x........: main (int.c:5)
The same test passed in valgrind-2.1.0. Since "int" is a common x86=20
instruction,
it should be supported by valgrind's VEX instruction translation layer.
Any ideas????
Regards,
Eduardo A. Mu=F1oz
|
|
From: Eduardo M. <ea...@us...> - 2006-02-08 19:23:48
|
I greed with you but this is a test from your test suite=20 none/tests/x86/init.c and the int.stderr.exp file has the following: Expected results from valgrind:=20 Process terminating with default action of signal 11 (SIGSEGV) GPF (Pointer out of bounds?) at 0x........: main (int.c:5) I gues you just need to change you test cases or modify the expected=20 results file. Regards, Eduardo A. Mu=F1oz |
|
From: Tom H. <to...@co...> - 2006-02-08 22:46:33
|
In message <OFF...@us...>
Eduardo Munoz <ea...@us...> wrote:
> I greed with you but this is a test from your test suite
> none/tests/x86/init.c and the int.stderr.exp file has the following:
>
>
> Expected results from valgrind:
> Process terminating with default action of signal 11 (SIGSEGV)
> GPF (Pointer out of bounds?)
> at 0x........: main (int.c:5)
>
>
> I gues you just need to change you test cases or modify the expected
> results file.
Ah yes, we know that test fails at the moment as VEX doesn't yet
generate the right sort of trap for certain obscure instructions.
The test is left in because one day we would like to get back to
the point where everything that worked with the old UCode engine
works with VEX but obscure things like that are still relatively
low priority.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-02-08 17:14:29
|
In message <OFB...@us...>
Eduardo Munoz <ea...@us...> wrote:
> In a IA32 machine, write and compile the following test program:
> ~~~~~
> #include <stdlib.h>
> int main(int argc, char **argv)
> {
> asm ("int $129");
> exit(0);
> }
> ~~~~~
What are you trying to achieve? Only int 0x80 normally does anything
much on an x86 linux system I thought?
> The same test passed in valgrind-2.1.0. Since "int" is a common x86
> instruction, it should be supported by valgrind's VEX instruction
> translation layer.
Only int 0x80 is common under linux, and that is supported.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@in...> - 2006-02-08 17:33:44
|
Am Mittwoch, den 08.02.2006, 11:02 -0600 schrieb Eduardo Munoz: > The same test passed in valgrind-2.1.0. Since "int" is a common x86 > instruction, It isnt common on x86 Linux, and valgrind was written mainly for Linux. Under Linux only the syscall int 80 is used for anything, and following the "implementation on demand" policy of valgrind it has not been implemented. > it should be supported by valgrind's VEX instruction translation > layer. Id disagree. Running your example program should probably segfault anyways. greets Dennis |
|
From: Nicholas N. <nj...@cs...> - 2006-02-09 05:37:19
|
On Wed, 8 Feb 2006, Dennis Lubert wrote: >> The same test passed in valgrind-2.1.0. Since "int" is a common x86 >> instruction, > It isnt common on x86 Linux, and valgrind was written mainly for Linux. > Under Linux only the syscall int 80 is used for anything, and following > the "implementation on demand" policy of valgrind it has not been > implemented. >> it should be supported by valgrind's VEX instruction translation >> layer. > Id disagree. Running your example program should probably segfault > anyways. The only use of int other than 'int 0x80' that I've seen is one JVM used it for generating certain kinds of exceptions (eg. array bounds exceptions). It worked prior to 3.0.0 and would be nice to get working again. Nick |