rr's reverse execution is gated by a microarchitecture list, a kernel floor, and one waitid flag

The project page has no install command, only a pointer to the wiki

Read what the page actually gives you. One paragraph on what rr is, one paragraph of system requirements, and three links: rr-project.org for general information, the wiki page Building-And-Installing for how to install, run, and build, and the extended technical report, Engineering Record And Replay For Deployability, hosted as an arXiv PDF, as the best technical overview available. Contributions are routed through a pull request checklist in CONTRIBUTING.md, and there is a wiki page for testimonials. Consequence for a first-time user: nothing on the project page can be typed into a terminal. Every decision about how to obtain the binary, which packages exist, and what to build from source lives one click away, so the page functions as a router rather than as a guide.

CPU eligibility is per microarchitecture, and two of the three cases defer to a wiki

The requirement is not a brand list. It is an Intel CPU with Nehalem, dated 2010, or a later microarchitecture; certain AMD Zen or later processors, with the specifics on a wiki page named Zen; and certain AArch64 microarchitectures, with ARM Neoverse N1 and the Apple Silicon M-series given as the examples. Consequence: a reader who checks only the manufacturer misses the rule. The gate is per microarchitecture, the Intel boundary is dated to 2010, and the AMD case is deferred to the Zen wiki page and the AArch64 case is given only as examples, so anything older than Nehalem on Intel and anything not on the Zen or AArch64 lists is out.

The kernel floor is 4.7, and the escape hatch is version 5.6.0

The stated system requirement is a Linux kernel of 4.7 or newer, and the reason is given precisely: support for `__WALL` in `waitid()`. One exception is recorded, that rr 5.6.0 worked with kernel 3.11 and required `PTRACE_SETSIGMASK`. Consequence: the historical workaround is welded to a specific old release, so anyone still on a pre-4.7 kernel has to pin an rr version from before the current line and accept whatever else has changed since, and the page names no newest-tested kernel ceiling, so a reader on a bleeding-edge kernel has no way to tell from the documentation whether their combination is covered.

Virtual machines need virtualized performance counters, and Xen is excluded outright

Running inside a VM guest is supported on one condition: the VM must support virtualization of hardware performance counters. What follows is a status list rather than a guarantee. Some configurations of VMware and KVM are known to work, some configurations of AWS and GCP VMs are known to work, and no configurations of Xen are known to work. Consequence: cloud use is not a general answer, it is a per-instance answer, so an EC2 or GCE machine type that does not expose counters will not run rr and the documentation does not enumerate which ones do; and the Xen line is a negative statement with no alternative offered, which leaves Xen users with nothing but the wiki to consult.

Five build and packaging routes sit in the tree, and the page names none of them

The top level of the repository contains CMakeLists.txt, a configure script, rr.spec, a snap/ directory, a Vagrantfile, .android/, scripts/, third-party/, a release-process/ directory, and a .buildkite/ directory for continuous integration, next to .clang-format, CONTRIBUTING.md, CODE_OF_CONDUCT.md, and LICENSE. That is an RPM spec, a snap package, a CMake build, a configure script and a Vagrantfile, all in one repository. Consequence: each route carries its own cost, from distro packaging rules for the spec to snap confinement, and since the project page describes none of them, the person choosing has to read the tree before knowing whether their distribution already ships a package.

The dependency tree is vendored and its terms are not discussed

A third-party/ directory sits at the top level next to src/ and include/, which conventionally holds vendored dependencies. The project page says nothing about what that directory contains, which projects are in it, or what licences they carry, and the same silence applies to the licence situation of rr itself: the repository's own LICENSE file is present in the tree, but nothing on the page names a licence. Consequence for a company evaluating vendoring: the compatibility and licensing questions that matter for a debugger distributed as a binary or built from source both have to be answered by reading LICENSE and third-party/ directly, because neither the page nor the contribution section addresses them.

Reverse execution rides on gdb, and master has moved past the newest tag

The mechanism is stated in one sentence: rr extends gdb with efficient reverse execution, and that combination with standard gdb and x86 features such as hardware data watchpoints is what makes debugging easier. It records, replays, and debugs execution of applications, described as trees of processes and threads, so the unit of work is a whole process tree rather than one program. Two consequences follow. First, rr is not a standalone front end, and hardware watchpoints are part of the intended workflow, which limits how far you can go without gdb present. Second, the most recent releases are 5.10.0 (2026-10-15), 5.9.0 (2025-02-13) and 5.8.0 (2024-05-20), while the default branch master last received a push on 2026-11-02, so building master gets you code newer than the last published release.

Editorial conclusion

rr fits a Linux developer debugging a multi-process or multi-threaded failure who needs to run a program backwards and already owns a Nehalem-or-newer Intel, a listed AMD Zen, or a listed AArch64 core on kernel 4.7 or newer. It does not fit anyone on Xen, on a pre-2010 Intel part, or on a cloud instance whose hypervisor does not virtualize hardware performance counters, and it does not fit a team that needs a licence answer from the repository metadata, since the licence field carries no name. Before installing, read the Building And Installing wiki, confirm your CPU against the Zen wiki page or the AArch64 microarchitectures named in the README, and check whether your kernel predates 4.7, in which case the only documented fallback is the older 5.6.0 line.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. rr-debugger/rr on GitHub