|
From: Josef W. <Jos...@gm...> - 2011-11-22 11:34:47
|
On 22.11.2011 06:50, John Reiser wrote: >> Another candidat seems to be the access counters incrementing all the time >> (and the indirection to get to the counters). It should be possible to do one >> counter per side exit, and add up the final counters at the end. > Unfortunately in general Kirchhoff's law does _NOT_ apply to software > because of things like setjmp/longjmp, getcontext/setcontext, exit(), > debuggers, etc. If you want to know how many times something is executed, > then you must count that directly. Hmm. You are right, one has to be careful. For setjmp/longjmp, getcontext/setcontext, and exit(), they are guest instructions doing a control flow change, so they should result in regular (side) exits of a superblock. For these, I do not see a problem. Signals are delivered between execution of superblocks, so these should be fine as well. The problematic case for above strategy are exceptions/traps. In that case, we would not count the executions in a block up to the exception. Hmm.. Cachegrind/Callgrind/Lackey all are buggy in that regard, as they delay the handling of memory accesses by instrumenting callbacks directly before side exits. This not only saves time because of getting rid of saves/restores of registers around each callback (there is nothing to save/restore between multiple callbacks in a row), but more importantly allows merging the events to reduce the number of callbacks. So by incrementing a counter before side exits should give the same result as currently: we already miss simulator calls on exceptions raised in the middle of a block :-( It seems that a tool can catch exceptions. There, it should be able to write compensation code. But to call the missed simulator calls, I am not sure how to get at the arguments saved in temporary registers in the instrumented block ... Josef > |