improving replay performance
robert at ocallahan.org
Sat Nov 21 00:02:34 UTC 2015
On Sat, Nov 21, 2015 at 12:22 PM, Chris Jones <jones.chris.g at gmail.com>
> On Fri, Nov 20, 2015 at 3:06 PM, Robert O'Callahan <robert at ocallahan.org>
>> On Sat, Nov 21, 2015 at 12:00 PM, Chris Jones <jones.chris.g at gmail.com>
>>> On Thu, Nov 19, 2015 at 6:32 PM, Robert O'Callahan <robert at ocallahan.org
>>> > wrote:
>>>> * After we've replayed a set of buffered syscalls, we need to induce a
>>>> ptrace stop so that rr can regain control and begin replaying the following
>>>> event. I've thought of many ways to do this, none of which are wholly
>>> I don't quite understand the problem here ... since the buffer flush
>>> (virtual event) was triggered by the next (real) event, can't we just
>>> discard the buffer flush event after restoring the saved data and start
>>> replaying the next one?
>> In most cases, yes, but sometimes after flushing the last event we need
>> to set the notify_on_syscall_hook_exit flag.
> Ah, that's a new one for me :). How about recording an event when you
> set the flag during recording?
That's how we handle signals during syscall buffering now, by setting that
flag. We don't want to record an event for setting that flag because we
can't safely replay to it. You have given me an idea though: replace the
boolean flag with a num_rec_bytes to stop at. Then during replay we can set
the flag early and we'll stop after the correct event, and the control flow
will be the same as during recording.
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea
.a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev