3 ms·
That is true, but there is always https://rr-project.org https://rr-project.org for easy reverse debugging if you're having trouble figuring out where you came
by haberman 6y ago
That is true, but there is always https://rr-project.org https://rr-project.org for easy reverse debugging if you're having trouble figuring out where you came from.
If the alternative is to drop to assembly, a C-based approach seems quite easy to debug. You can just add printf() statements! Previously when I had been using assembly language or a JIT, I had to resort to techniques like this: https://blog.reverberate.org/2013/06/printf-debugging-in-assembly-language.html https://blog.reverberate.org/2013/06/printf-debugging-in-ass...
- jhgb 6y ago> but there is always https://rr-project.org https://rr-project.org for easy reverse debugging if you're having trouble figuring out where you came from How did I not know about this? Thanks!
- jpgvm 6y agorr is really a hidden treasure. C/C++ wasn't the same for me after discovering it. It's sort of like the first time you learn about interactive debugging. Everything you did before that suddenly feels like "caveman coding" and you never want to go back.
- kevincox 6y agoOf course RR is too expensive to be deployed in production builds. So if you are getting core dumps from "production" you won't have this information. So while RR helps it doesn't completely mitigate the tradeoff.
- deleted 6y ago[deleted]
- touisteur 6y agoYou may be interested in Intel PT snapshots in Linux core dumps, that gdb knows how to interpret and will give you a detailed branch trace. Less cool than rr but still very interesting!
- elcritch 6y agoPerhaps a "ring logger" approach could be useful. Append the more useful bits of what would normally go into the stack frame but without the allocation overhead. Seems like a few memcpy's and modulo operations wouldn't hurt the code gen too much.