Argh, reply all is needed. On May 19, 2013 4:45 PM, "Brendan Dolan-Gavitt" <brenda...@gatech.edu> wrote:
> We had to do something similar for our (soon to be released) record and > replay implementation. To ensure interrupts are delivered at precisely the > right time we added a global 64 bit instruction counter and then modified > translate.c for each architecture to emit tcg ops that increment it before > each instruction. At the end of translating a TB we store the number of > instructions in that TB. > > Then during replay, before every basic block executes (we disabled > chaining) we check whether the current instruction count plus the number of > instructions in the next TB is greater than the instruction count recorded > for the next interrupt. If so, we retranslate and terminate the block at > the right point so we can deliver the interrupt. > > There is one gotcha to this, which is that care had to be taken to not > interfere with the search_pc mechanism. > > If the above explanation isn't clear feel free to ask questions or just > wait 2 weeks and read the code. I'm not sure how much work it would be to > integrate what we have into the gdb stub but I'd be delighted if someone > took on the task. > > Cheers, > Brendan > On 19 May 2013 21:09, Mark Burton <mark.bur...@greensocs.com> wrote: > > Note - what I understand by a basic block is something that ends > in a > > jump/branch of some description. Hence, one thing I think you can say > about a > > basic block is that each PC value within it is unique. Hence, if I know > the > > number of basic blocks executed, and the current PC, then I should be > able to > > re-run to there (assuming a deterministic system of course). > > Assuming your rerun is strictly deterministic so you always exit > the basic block the same way each time, then yes, this amounts > to optimising the "instruction count" by doing it as "X basic > blocks then Y instructions". You could actually have this > really do the instruction count for you, if you track insns > per block at translation time. (There is some fiddling necessary > when we take an unexpected exception in the middle of a block > due to a load/store fault.) > > > I'd be interested to know (a) if there is a sensible place for > > adding a basic block counter, and (b) if people like this route > > better or worse than an instruction counter? > > I think you're probably best off getting the instruction counter > working properly before trying to optimise it... > > thanks > -- PMM > >
