Another couple of differences: No support for rr because of some lack of performance counters[1]. I also found that lm-sensors can barely see my AMD Ryzen at all, missing all core temp information. I'm hoping that both of these will be fixed since it doesn't seem that AMD is missing anything intrinsicly.
[1] https://github.com/mozilla/rr/issues/2034
In AMD is dominating Intel in Amazon's best-selling CPUs listrr-debugger
rr
C++2014–2025
rr-debugger / rr
rr
Record and Replay Framework
57Distinct people
68Mentions
0Explicit recommenders
10.7KGitHub stars
What to know before exploring
What it is
Record and Replay Framework
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 8:59:20 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year68 dated mentions
Observed mentions: 2014-03-26 12:19:18 UTC to 2025-06-28 03:42:02 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Overview
rr is a lightweight tool for recording, replaying and debugging execution of applications (trees of processes and threads).
Debugging extends gdb with very efficient reverse-execution, which in combination with standard gdb/x86 features like hardware data watchpoints, makes debugging much more fun. More information about the project, including instructions on how to install, run, and build rr, is at https://rr-project.org. The best technical overview is currently the paper Engineering Record And Replay For Deployability: Extended Technical Report.
Or go directly to the installation and building instructions.
Please contribute! Make sure to review the pull request checklist before submitting a pull request.
If you find rr useful, please add a testimonial.
rr development is sponsored by Pernosco and was originated by Mozilla.
System requirements
Linux kernel >= 4.7 (for support of __WALL in waitid())
rr 5.6.0 worked with kernel 3.11 (requiring PTRACE_SETSIGMASK)
rr currently requires either:
An Intel CPU with Nehalem (2010) or later microarchitecture.
Certain AMD Zen or later processors (see https://github.com/rr-debugger/rr/wiki/Zen)
Certain AArch64 microarchitectures (e.g. ARM Neoverse N1 or the Apple Silicon M-series)
Running in a VM guest is supported, as long as the VM supports virtualization of hardware performance counters.
Some configurations of VMware and KVM are known to work.
Some configurations of AWS and GCP VMs are known to work.
No configurations of Xen are known to work.
AI usage policy
When submitting issues or PRs, please clearly indicate how LLMs were used. Issues or PRs which appear LLM-generated but carry no such indications may be closed without comment.
When submitting PRs for review, the submitter must be human and take full responsibility for understanding the changes, regardless of how LLMs were used.
Read the full README on GitHubWhat Hacker News says
11 sourcesChanging that is a work in progress: https://github.com/mozilla/rr/issues/2034
In AMD is dominating Intel in Amazon's best-selling CPUs listhttps://github.com/mozilla/rr/issues/1373 is tracking that, but the short story is that ARM seems to not provide enough performance counters to make the current rr approach work at the moment. So it would take either CPU-side changes or a somewhat different approach.
In Debuggers SuckFWIW, rr support for AMD CPUs is getting close. See https://github.com/mozilla/rr/issues/2034#issuecomment-55649...
In Debuggers SuckThe only real negative one is that rr ( https://github.com/mozilla/rr ) is not available on Ryzen for now.
Other than that, you are safe.
In AMD Q4:16-core Ryzen 9 3950X, Threadripper Up To 32-Core 3970XThey have been working on AMD support, see for example: https://github.com/mozilla/rr/issues/2034
The problem is that AMD CPUs have lots of bugs in their performance counter implementation. Intel CPUs don't have those bugs. With newer generations of AMD CPUs, AMD has fixed some of these bugs, but others remain.
I wonder why AMD hasn't stepped up to get involved in this project. There might be nothing that can be done with currently shipping silicon, but at least AMD could make sure that on their future silicon it all works. Fixing their performance counter bugs would likely benefit other projects as well.
In AMD vs. Intel CPU Market Share: 7nm Makes Landfall as Price War BeginsWhen I was building a PC last December, I considered AMD until I saw that https://github.com/mozilla/rr requires an Intel processor.
> rr currently requires an Intel CPU with Nehalem (2010) or later microarchitecture.
I don't even use rr at the moment, but I hate the idea of building a monster machine only to find that I'm left out of some cutting-edge technology because I went off-brand.
In AMD vs. Intel CPU Market Share: 7nm Makes Landfall as Price War BeginsThe mozilla/rr debugger doesn't work on Ryzen CPUs - https://github.com/mozilla/rr/issues/2034
(rr stands for Record and Replay Framework, it's a gdb extension which allows for reverse execution)
In $499 AMD Ryzen 9 3900X Almost as Fast as $2000 Intel Core I9-9980XENotable is that such a debugger, that records the entire exrcution and allows you to go back in time, already exists for compiled languages in the form of a gdb plugin: https://github.com/mozilla/rr
In JavaScript debuggers are brokenThe history here is a bit as follows. Back about four years ago, I set out to write a debugger for Julia and while I was at it, I figured I might as well fix all of the other things that have always bothered me about debugging. As an example of that, it had the following features:
- Being completely written from scratch in Julia
- Mixed debugging between Julia and C/C++ code
- Integration with https://github.com/mozilla/rr for time traveling debugging
- Debugging windows programs running on a linux host under wine (and in particular even as an rr replay).
- Zero overhead debugging by using mixed modes (DWARF based debugging generally, a much more accurate interpreter based one when possible).
- Very precise location tracking, on an expression basis, not just a line-by-line basis
- Multi-process debugging by riding along RPC
Read the rest
calls, even across machine and even as separate rr recordings across machines
As you can tell from this feature list, that project was a bit over ambitious and in the end failed to be a particularly useful debugger for Julia. It was useable for a bunch of basic cases, but fairly brittle. Also, then 0.6 came around and all of Julia's internal APIs changed and porting over the entirety of Gallium would have been quite hard.
After 0.6 was released, I decided this wasn't working out for a Julia debugging story and pulled out just the interpreter and UI parts from Gallium (that package was called ASTInterpreter2.jl). This worked ok, but was lacking a bunch of features that I never got around to implementing, because the lead up to 1.0 required a whole bunch of compiler work that nobody else was available to do. This work now is based on that work from 0.6, but actually making it work nicely and paying a whole lot of attention to it that I was never able to. I'm very happy that Tim, Kristoffer and Sebastian decided to take this on, because I feel like my workload has only increased over the past year ;).
I still very much want all the ambitious features from above, and we do still have the code (and much of it is actually in use, just not for debugging) and I'm fully expecting them to make a recurrence. However, this time around, we'll start with a stable, usable system and gradually make it faster and add features, rather than building an unstable system with all the features and trying to fix it. The former approach is much better for getting usable tools out (though sometimes the latter can lead to more interesting results in a research setting). The other thing to note is that Julia is much more stable now, so it's easier to keep things running without breaking every few months.