Module Linker VS rr

Hi, in case you're not already aware of the name clash, there's already a `rr` in the programming world. It's "record and replay": https://rr-project.org/.

Very different, but a very fine tool tool.

I don't know, however a key element is:

> Record/replay system is based on saving and replaying non-deterministic events

> The following non-deterministic data from peripheral devices is saved into the log: mouse and keyboard input, network packets, audio controller input, serial port input, and hardware clocks (they are non-deterministic too, because their values are taken from the host machine). Inputs from simulated hardware, memory of VM, software interrupts, and execution of instructions are not saved into the log, because they are deterministic and can be replayed by simulating the behavior of virtual machine starting from initial state.

So, it's probably not much, you can probably comfortably save minutes of qemu sessions.

Also note the existence of the rr debugger [1], which allows you to reverse debug applications with a ~10% performance hit while recording. To achieve this, it records results of syscalls (only). It will serialize thread events, so have the effect of running applications like on a single core CPU.

[1] https://rr-project.org/

rr.

rr rr rr rr.

rr!

When testing "algorithmic" modules like compilers, it's basically a productivity cheat code to run the tests under https://rr-project.org/. Doing so allows you to deterministically replay execution, seeking forwards and backwards in the timeline of your program's execution, and quickly locate what went wrong in any computation.

For example, if we have

    struct CircleDescription {

It says on https://rr-project.org/ that it supports Go programm, what's the status?

This was because no matter how hard I tried, I kept running into variables that I was watching that appeared to be the same reference, have different values (so I know I was referring to something wrong, but could not for the life of me figure it out, and though if I only had a way to step/trace and do this visually like an AST that highlights changed values and you could see back to its root where it's actually being modified visually)

I found out there's a thing called "deterministic debugging" (and the biggest known example afaict is rr: https://rr-project.org/

Apparently MS has a time-travel debugger... I pictured the AST being populated and repopulated via the steps, and the ability to diff changes over time.

Here's a wiki on various systems, though most of these seem to be typical text based "trace" options.

https://en.wikipedia.org/wiki/Time_travel_debugging

I think this tool must share a lot techniques and use cases with rr. I wonder how it compares in various aspects.

https://rr-project.org/

rr "sells" as a "reversible debugger", but it obviously needs the determinism for its record and replay to work, and AFAIK it employs similar techniques regarding system call interception and serializing on a single CPU. The reversible debugger aspect is built on periodic snapshotting on top of it and replaying from those snapshots, AFAIK. They package it in a gdb compatible interface.

Hermit also lists record/replay as a motivation, although it doesn't list reversible debugging in general.

Interesting. Perhaps you can inspect the disassembly of the function in question when using Graal and HotSpot. It is likely related to that.

Another debugging technique we use for heisenbugs is to see if `rr` [1] can reproduce it. If it can then that's great as it allows you to go back in time to debug what may have caused the bug. But `rr` is often not great for concurrency bugs since it emulates a single-core machine. Though debugging a VM is generally a nightmare. What we desperately need is a debugger that can debug both the VM and the language running on top of it. Usually it's one or the other.

> In general I’d argue you haven’t fixed a bug unless you understand why it happened and why your fix worked, which makes this frustrating, since every indication is that the bug exists within proprietary code that is out of my reach.

Were you using Oracle GraalVM? GraalVM community edition is open source, so maybe it's worth checking if it is reproducible in that.

[1]: https://github.com/rr-debugger/rr