3 ms·

My previous job was in compiler engineering and I worked on upstream LLVM for a little while. rr was indispensable for me — not just for debugging, but as a too

My previous job was in compiler engineering and I worked on upstream LLVM for a little while. rr was indispensable for me — not just for debugging, but as a tool for understanding how the compiler works in general. For example: you can set a watchpoint on an object in memory, and reverse-execute to the point where it was instantiated. This allowed you to answer questions such as ‘which optimisation pass was responsible for creating this DAG node?’ and such. Really powerful tooling — I haven’t kept up with it for a while, but last I checked it didn’t work on aarch64/arm64 because of a lack of certain performance counters only available on x86 hardware. The lack of support for other languages (e.g. Go) is also a shame. This has unfortunately rendered it unviable for my day job! If you’re working in a stack where it’s supported, it’s really quite special.

dzaima 2y ago
I believe rr should support other languages exactly as well as gdb does; I've looked at some Rust in it once or twice at least, and IIRC even some Go; though I'm happy enough with doing assembly-level breakpoints/whatnot so I can't comment on more fancy things. Even some OpenJDK JIT! (though there of course source-mapping/stacktraces are non-existent, never mind reading variables, but even then I managed to hack together some basic source-mapping at https://github.com/dzaima/grr#java-jit https://github.com/dzaima/grr#java-jit; though it's rather unusable with rr due to OpenJDK's machine code dumping going directly to stdout, and general slowness). That said, it would be very neat to have a more complete standard debugging interface across ahead-of-time-compiled code, interpreters, and JITs. And it does have some aarch64 support by now, though it'll still require a suitable CPU with necessary perf counters.
- adgjlsfhk1 2y ago
  I do know that RR works for Julia. Not sure why it wouldn't work for Go.
  - dzaima 2y ago
    Julia goes through LLVM, which has good DWARF support (and, additionally, until recently, Julia hosted rr's CI, so Julia directly cares about rr). Whereas AFAIU Go does its codegen fully from scratch, without much regard for gdb/DWARF quality.
Thaxll 2y ago
It says on https://rr-project.org/ https://rr-project.org/ that it supports Go programm, what's the status?
roca 2y ago
rr supports Aarch64 pretty well now.

dzaima 2y ago

I believe rr should support other languages exactly as well as gdb does; I've looked at some Rust in it once or twice at least, and IIRC even some Go; though I'm happy enough with doing assembly-level breakpoints/whatnot so I can't comment on more fancy things. Even some OpenJDK JIT! (though there of course source-mapping/stacktraces are non-existent, never mind reading variables, but even then I managed to hack together some basic source-mapping at https://github.com/dzaima/grr#java-jit https://github.com/dzaima/grr#java-jit; though it's rather unusable with rr due to OpenJDK's machine code dumping going directly to stdout, and general slowness). That said, it would be very neat to have a more complete standard debugging interface across ahead-of-time-compiled code, interpreters, and JITs. And it does have some aarch64 support by now, though it'll still require a suitable CPU with necessary perf counters.

adgjlsfhk1 2y ago
I do know that RR works for Julia. Not sure why it wouldn't work for Go.
- dzaima 2y ago
  Julia goes through LLVM, which has good DWARF support (and, additionally, until recently, Julia hosted rr's CI, so Julia directly cares about rr). Whereas AFAIU Go does its codegen fully from scratch, without much regard for gdb/DWARF quality.

Thaxll 2y ago

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

roca 2y ago

rr supports Aarch64 pretty well now.