|
From: Jeroen N. W. [Bahco] <jn...@xs...> - 2007-11-24 05:29:03
|
On Fri, 23 Nov 2007, Nicholas Nethercote wrote: > > On Fri, 23 Nov 2007, Gregor Jasny wrote: > >> I've got an idea for a MMX checker tool. First some background: >> When you use MMX/SSE instructions on the x86 platform you have to reset >> the FPU stack with the 'emms' instruction after calculations finished. >> Otherwise the following floating point instructions will fail. >> >> I have a large C++ project here and somewhere in an static initializer >> such an reset is omitted. Spotting the missing place is quite hard. >> I've tried to use GDB to watch the $ftag register, but GDBs single >> instruction stepping takes ages. >> >> So the valgrind tool should do the following: If an FPU instruction is >> executed with a corrupt FPU stack, print the position of the last >> MMX/SSE instruction. >> >> I've skimmed the lackey source code, but have still no idea where to >> start. It would be nice if you could provide me some assistance or even >> some source code. >> >> What do you think? > > It might be possible. If it is possible, it probably wouldn't be all that > hard, i.e. the source code needn't be that long, but understanding > Valgrind > enough to write it requires some effort. > > The key factor is that Valgrind translates x86 (or PPC) code into an > intermediate representation (IR). The question is whether the IR > preserves > the 'emms' instruction in such a way that you can recognise it. Judging > from VEX/priv/guest-x86/toIR.c:do_EMMS_preamble() (around line 5090), it's > not represented explicitly, but rather all the FP regs get zeroed, as does > the FP stack top. You might be able to detect that manually; it's > conceivable that an optimisation pass might remove some of the zeroings if > it knew they weren't necessary, but I don't know how likely that is. > > To understand the IR, look at VEX/pub/libvex_ir.h. Make sure you use the > SVN version, it has much better comments in it than the 3.2.3 version. > Then, Memcheck might be a better example tool than Lackey, to see how a > wider range of instructions are handled. Maybe I'm wrong, but does this tool have to deal with actual IR at all? As this tool seems to be x86-specific, wouldn't an inspection of the IMarks yield all the information this tool needs? (IIRC, IMark has been renamed in valgrind trunk.) Just my two cents ... Jeroen. |
|
From: Julian S. <js...@ac...> - 2007-11-24 10:09:14
|
On Saturday 24 November 2007 06:28, Jeroen N. Witmond [Bahco] wrote: > Maybe I'm wrong, but does this tool have to deal with actual IR at all? As > this tool seems to be x86-specific, wouldn't an inspection of the IMarks > yield all the information this tool needs? (IIRC, IMark has been renamed > in valgrind trunk.) Yes. That's exactly right. You can use the IMark to get a pointer to each instruction, and then look at the instruction as much as you like. J |