|
From: Nicholas N. <nj...@ca...> - 2003-11-20 22:08:14
|
On Thu, 20 Nov 2003, Julian Seward wrote: > > Note that VG would be quite slow if it had to check if a write instruction > > is about to change already instrumented code (Wasn't this the > > case in the first days of VG?). > > Urk, uncooperative self-modifying code. That's horrible. I guess we _could_ > reinstate the old-days check-every-write thing that Josef mentions, by default > off but controlled by a command line flag. That way, normal runs are not > slowed down but you can ask for s-m-c support if you really want. Can you remember what kind of slowdown this caused? Checking every write sounds expensive. > Or perhaps we can merge this with Jeremy's need to have precise exceptions > to support full virtualisation, in a single flag --paranoid-vcpu=yes|no [no] ? The nasty thing is that most users won't even realise they're using run-time generated code with nested functions (hell, I didn't) so they won't know to turn on whatever option is required to handle it properly. And a lot of the time it will work, but occasionally things will go subtly wrong when two nested functions put code at the same address. Ideally, we want a cheap way of detecting s-m-c that can be on all the time (then we could get rid of the INVALIDATE_TRANSLATIONS macro). I have an extremely vague idea about tracking things at the page level, and possibly throwing out all translations that come from code within a page in certain circumstances. Or something. Hmm. Or maybe we can convince the GCC folks to remove support for nested functions :) N |