|
From: Steve F. <sf...@re...> - 2003-08-19 02:34:57
|
I used to be able to valgrind my app, but these days I always run into unimplemented instructions. I have changed several pieces of the puzzle since the last time I was able to successfully run, but I was hoping someone might have an idea. I am using the NVIDIA driver with the __GL_FORCE_GENERIC_CPU flag. I have no reason to suspect that there is any problem with this. I am also using Intel's IPP libraries that make heavy use of MMX and SSE acceleration. They provide versions that are not supposed to contain any MMX code, and I am linking with these. I suspect there may be a problem here, especially since I have upgraded versions since my last successful valgrind run. By liberally spreading printouts through my code and running it under valgrind, it appears that what is happening is that my application calls something in libpng, which calls the pow() function, which has been overridden by the IPP libraries. When disassembled by gdb, IPP's pow() seems to autodetect whether the CPU it is running on supports MMX, and dynamically selects a version of the function to run based on that. (I don't know *why* it is bothering to autodetect anything, since I told it to link with the non-MMX version of the library.) That detection appears to be resulting in it believing that it is running on an MMX processor (which it is, except for the valgrind VM layer). Fall down go boom. Or maybe I'm just horribly confused, and this isn't what's happening at all. I was mostly wondering if, now that valgrind supports MMX and some SSE, it is now reporting that it is an MMX/SSE cpu? If so, is there some way of making it act stupid again? (I don't know whether my problem is with MMX or SSE instructions, actually.) If it would help, I'll post the actual error message. I can't now, since it's on the other side of a very long recompile cycle. This is with valgrind-20030725, and also a CVS checkout from about a week ago. If nobody has any brilliant ideas, I guess I'll slog through downgrading each piece of the puzzle until I can valgrind again. Thanks! Steve |
|
From: Tom H. <th...@cy...> - 2003-08-19 06:19:41
|
In message <3F4...@re...>
Steve Fink <sf...@re...> wrote:
> I was mostly wondering if, now that valgrind supports MMX and some SSE,
> it is now reporting that it is an MMX/SSE cpu? If so, is there some way
> of making it act stupid again? (I don't know whether my problem is with
> MMX or SSE instructions, actually.)
I sent a patch to this list several weeks ago to stop valgrind
reporting the CPU as SSE capable for people with your problem.
There shouldn't be any problem with MMX as valgrind's MMX support
is supposed to be complete.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2003-08-19 08:05:17
|
On Tuesday 19 August 2003 07:18, Tom Hughes wrote: > In message <3F4...@re...> > > Steve Fink <sf...@re...> wrote: > > I was mostly wondering if, now that valgrind supports MMX and some SSE, > > it is now reporting that it is an MMX/SSE cpu? If so, is there some way > > of making it act stupid again? (I don't know whether my problem is with > > MMX or SSE instructions, actually.) > > I sent a patch to this list several weeks ago to stop valgrind > reporting the CPU as SSE capable for people with your problem. > > There shouldn't be any problem with MMX as valgrind's MMX support > is supposed to be complete. Yes, the problem happens because the current cvs head, and 20030725 report whatever the real machine's CPUID report, but do not actually implement all the SSE insns. Hence the Intel libraries think the cpu is sse capable when in fact it isn't. A quick hack is to change the definition of VG_(helper_CPUID) in vg_helpers.S back to what it was in 1.9.6 or thereabouts, which claimed to be a pre-MMX pentium-I. That should fool the intel libraries appropraitely. J |