Messages in this thread | | | Date | Fri, 06 Jul 2007 12:51:27 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: Valgrinding the kernel? |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |