From: Julian S. <js...@ac...> - 2010-07-29 17:43:23
|
On Thursday, July 29, 2010, Barry L. Rountree wrote: > John Reiser wrote: > >>> ... Valgrind could stop > >>> simulated CPU and revert back to the real CPU part way through > >>> program execution." > >>> > >>> I'm not seeing this mentioned anywhere else in the documentation. > >>> Does this capability still exist? > >> > >> No .. that description I think is somewhat out of date. There > >> is no provision for switching back to native execution. > > > > In case somebody is really motivated, then example code for such > > a feature for x86 can be found by searching for the string 'letgo' in > > http://*bitwagon.com/valgrind+uml/valgrind-3.3.0-2007-12-27.patch.gz > > And reversing that process would put you back into emulation mode? > > (Yes, that question is eliding a lot of hairy details. But if the > program is started under valgrind and valgrind let's it go back into > native mode, then switching back to valgrind should /just/ [!] be a > question of updating valgrind's registers and hitting the big green > "GO" button, right?) But how would you do that? Once you switch to running on the real CPU, you lose all control and you no longer have the ability to decide when to switch back to emulation. Additionally, as John points out, the whole point of running on an emulator is to collect side-data about what's going on. For some tools (eg profilers) the missing parts of the execution is not too bad, you'll just get wrong statistics. But for the error checking tools, at least Memcheck and the thread checkers, you'll get guaranteed absolute chaos. So .. what is it you're _really_ trying to do? J |