I have two use cases:
- General performance analysis. For this more counters is generally incrementally better.
- Running https://github.com/mozilla/rr. This requires the retired-branch-counter to be available (and accurate - sometimes virtualization messes that up)
The second one I actually care more about, because I've pretty much stopped trying to debug software when rr is not available, too painful ;). Feel free to email me (email is in my profile) for gory details.
In EC2 Bare Metal Instances with Direct Access to Hardwarerr-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, 6:01:08 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
9 sourcesOne of the most common errors that i used to encounter when i first started with golang was- accessing a map without initializing it first. For example:
var m map[string]int
m["name"] = 23
which resulted in "panic: assignment to entry in nil map".
Nil pointer access errors are relatively easy to debug when in Go world, as compared to in CGO. Like, we are using zmq via CGO in one of our project and when these errors occured, we had to use gdb to debug (apart from logging). At one time we even used rr.
rr is really cool, everyone should check this out.
https://github.com/mozilla/rr
In Understanding Go panic outputrr does support multithreading[0].
"rr doesn't record shared-memory multithreading, so it forces your application's threads to execute serially. Your application can see an additional slowdown if it takes advantage of multicore parallelism."
[0]: https://github.com/mozilla/rr/wiki/Usage#recording-an-execut...
In Time Travel DebuggingMozilla has a similar tool, check it out:
https://github.com/mozilla/rr
In Time Travel DebuggingUnfortunately for me, the fact that rr can't run on Ryzen CPUs is a dealbreaker. :(
https://github.com/mozilla/rr/issues/2034
In AMD Ryzen Threadripper 1950X and 1920X Reviewhttps://github.com/mozilla/rr/issues/1373
This disappoints me, as I'd love to see rr ported to PowerPC, which is another LL/SC architecture that I suspect might run into this issue.
In Another Case of Obscure CPU Nondeterminismrr := https://github.com/mozilla/rr
rr is a lightweight tool for recording and replaying execution of applications (trees of processes and threads).
In Another Case of Obscure CPU NondeterminismThat's one thing I really miss in Vim when writing C++. I have reasonably good autocompletion with YouCompleteMe and good code indexing by a combination of exuberant-ctags and rtags, but no debugger integration. To me the editing gains outweigh the lack of GDB integration, since I only infrequently have to debug, but when I do I basically just open GDB in a separate terminal window and set it to "layout src". That said, I also get to use rr[1] from time to time and its productivity gains obliterate any downsides to having to type everything in the terminal, especially for debugging memory corruption. Just record your program until it crashes, then run it backwards with a breakpoint set on the corrupt memory address to see where it gets overwritten. Only downside is that it can't support shared memory.
[1] https://github.com/mozilla/rr
In Turning Sublime Text into a Lightweight Python IDEI would strongly suggest you check out rr - Mozilla's Record and Replay framework https://github.com/mozilla/rr . Don't let the name confuse you - it's not specific at all to Firefox. It can record a process's execution and replay it in gdb, and lets you step and continue backwards. This last point is super powerful - let's say you see that some variable has an unexpected value. You can set a watchpoint on it, then reverse-continue and gdb will stop at the point it was changed. It has been invaluable in finding some tricky bugs. Apart from that, you can also use it to explore the execution of a program, since you can freely step backwards and forwards in time. You also get a deterministic thread execution sequence each time. That might be either good or bad, depending on what you want.
In Working on Chrome made me develop a tool for reading source code