You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when we patch an instruction the instruction that is patched over is saved into a replay area. When a thread traps in on the breakpoint trap we eventually single step this replay instruction so that that effects are seen in the register set before we reset the trapped thread to after the original patched instruction. This sequence of events is only really required if we were to leave the breakpoint trap installed for a period of time to capture lots of objects. With the current scheme of objects being captured for a single thread we could just rewind the %rip of the trapping thread after putting the original instruction back and not do the whole replay sequence.
I'd actually we rather captured objects from multiple threads but it may not be too much work to do the above in the current scheme. The reason for doing this, obviously, is to not make the trapped thread do any more work than is absolutley necessary and keep induced latency to a minimum.
The text was updated successfully, but these errors were encountered:
Currently when we patch an instruction the instruction that is patched over is saved into a replay area. When a thread traps in on the breakpoint trap we eventually single step this replay instruction so that that effects are seen in the register set before we reset the trapped thread to after the original patched instruction. This sequence of events is only really required if we were to leave the breakpoint trap installed for a period of time to capture lots of objects. With the current scheme of objects being captured for a single thread we could just rewind the %rip of the trapping thread after putting the original instruction back and not do the whole replay sequence.
I'd actually we rather captured objects from multiple threads but it may not be too much work to do the above in the current scheme. The reason for doing this, obviously, is to not make the trapped thread do any more work than is absolutley necessary and keep induced latency to a minimum.
The text was updated successfully, but these errors were encountered: