> I do not know why the JMP is not just a RET, however.
This is caused by the CONFIG_RETHUNK option. In the disassembly from objdump you are seeing the result of RET being replaced with JMP __x86_return_thunk.
> The NOP instructions at the beginning and at the end of the function allow ftrace to insert tracing instructions when needed.
These are from the ASM_CLAC and ASM_STAC macros, which make space for the CLAC and STAC instructions (both of them three bytes in length, same as the number of NOPs) to be filled in at runtime if X86_FEATURE_SMAP is detected.
It's written in Rust and is based around a version of Bochs modified for deterministic execution. It's got time-travel debugging (with WinDbg), which works by replaying forward from the nearest snapshot to the point at which the user is asking to move backwards to.
I wrote a similar snapshot system for our deterministic trading engine. It's hard to imagine a system that doesn't do that unless you actually enforce every single event in your log to be reversible/non-destructive/non-aliasing. Even then, you still want snapshots to jump to a point in time. The only annoying thing is the case where you want to step back one, meaning a naive implementation would jump back to the last snapshot and play forward.
An 80% solution is to keep the last N states in memory. Snapshots compress well within a small time frame, so whenever we "paused" the playback, we could stash deltas from the pause point to reconstruct stuff (I sadly never got around to implementing this part before I left since it wasn't high enough priority).
> Even then, you still want snapshots to jump to a point in time. The only annoying thing is the case where you want to step back one, meaning a naive implementation would jump back to the last snapshot and play forward.
At Undo.io we use similar techniques to time travel debug C/C++ (and other languages).
> An 80% solution is to keep the last N states in memory.
We use a slightly more specialised version of what you describe - we maintain a set of snapshots at wide spacings throughout history (for big time jumps the user might want to do) and ones just a small gap before the "current time" the user is viewing, so small steps backwards can be fast too.
It's been a complex process figuring out an algorithm that balances these concerns without using up unreasonable amounts of RAM.
The other way to tackle slowness - though this is for larger jumps in history - is to search the timeline in parallel. Since you've got deterministic re-execution you can play several chunks of history at once while looking for a key event. It can't help for small jumps in time but if you are looking far into the past it can be a significant speed-up.
Wow I stumbled on Gamozolabs' youtube when looking into determinism and hypervisors. Didn't know he also worked on TKO for MSFT. Glad he is making a similar project!
The trick at Microsoft is to start working on your project in your spare time. Then incorporate it into your project at MSFT. You get the clout associated with having an open source project but then you also get to use it internally as a sanctioned tool
> The trick at Microsoft is to start working on your project in your spare time. Then incorporate it into your project at MSFT.
(Ex-msftie here)
Microsoft is great for being amongst the tiny number of software companies that not only allow their FTEs to have their own software projects without attempting to claim any kind of ownership (compare with Apple where I’m told having even a public GitHub account without manager-approval is grounds for termination…) - but MS even actively encourages it too (though I cynically note that was when the Windows Phone App Store’s app-shortage was thought-of as a serious problem)
BUUUUT - they do require you to strictly avoid cross-over with their own products: you can’t just re-use your own code in a company project, or even reimplement it from-memory. Yes, there are ways of doing this properly (involving weeks of meetings with LCA arranging a permanent irrevocable - and possibly exclusive - rights transfer), wasting time better spent on other things) - so your project had better be something special and you’d need to give-up hope of getting rich from it (spare a very modest bonus the year you do the LCA paperwork if your skiplevel sees any value in it).
Yeah, and that is how stuff like C++/CX gets killed, replaced by a side project that was never at the same tooling level in Visual Studio, even though there was a CppCon talk promising otherwise, and currently is in maintenance state because "it achived its goals", who cares about those paying customers that had to rewrite their code to a lesser capable tool, now abandonend.
This is caused by the CONFIG_RETHUNK option. In the disassembly from objdump you are seeing the result of RET being replaced with JMP __x86_return_thunk.
https://github.com/torvalds/linux/blob/v6.1/arch/x86/include...
https://github.com/torvalds/linux/blob/v6.1/arch/x86/lib/ret...
> The NOP instructions at the beginning and at the end of the function allow ftrace to insert tracing instructions when needed.
These are from the ASM_CLAC and ASM_STAC macros, which make space for the CLAC and STAC instructions (both of them three bytes in length, same as the number of NOPs) to be filled in at runtime if X86_FEATURE_SMAP is detected.
https://github.com/torvalds/linux/blob/v6.1/arch/x86/include...
https://github.com/torvalds/linux/blob/v6.1/arch/x86/include...
https://github.com/torvalds/linux/blob/v6.1/arch/x86/kernel/...