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. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
