Jeff Dike wrote:
On Fri, Jul 06, 2007 at 10:30:19AM -0700, Dan Kegel wrote:
Could you give it a shot?
OK, after ripping out the code that broke valgrind last time (patch
below), I get this:
==27590== Warning: set address range perms: large range 516194304, a 0, v 0
Hm, wonder what that is...
vex x86->IR: unhandled instruction bytes: 0xF3 0xAF 0x74 0x9
==27590== Your program just tried to execute an instruction that Valgrind
==27590== did not recognise. There are two possible reasons for this.
==27590== 1. Your program has a bug and erroneously jumped to a non-code
==27590== location. If you are running Memcheck and you just saw a
==27590== warning about a bad jump, it's probably your program's fault.
==27590== 2. The instruction is legitimate but Valgrind doesn't handle it,
==27590== i.e. it's Valgrind's fault. If you think this is the case or
==27590== you are not sure, please let us know.
==27590== Either way, Valgrind will now raise a SIGILL signal which will
==27590== probably kill your program.
==27590==
Maybe the problems after that will be more pedestrian.
Doesn't look like it.
FWIW, that instruction is repz scas. In an earlier valgrind effort in
2002, I hit repe scas
(http://www.goop.org/~jeremy/valgrind/76-repe-scas.patch), so maybe
something similar is needed here.
The virtual CPU code has been competely rewritten since then. If its a
non-gcc generated instruction, its possible the new code
parser/generator hasn't been taught to deal with it.
I'm willing to focus a little effort on this.
I guess you'll have to fix valgrind's various bugs. See, simple :)
Exactly ;)
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
