3 ms·
It's sad that all of this would have been a lot easier if only the x86-64 C ABI didn't decide to say "Eh, you don't have to reserve rbp and rsp for stacks". Th
by boulos 12y ago
It's sad that all of this would have been a lot easier if only the x86-64 C ABI didn't decide to say "Eh, you don't have to reserve rbp and rsp for stacks".
The code to unwind C-code that follows rbp and rsp is super trivial (and lightning fast). Once you get into the hell of DWARF you're talking tons and tons of cycles. In all cases, dealing with inlined functions is messy and imprecise (one of the reasons I've heard for not relying on rbp/rsp), but when building a runtime it just feels sad to have tossed out the stack frames.
- nly 12y agoI don't get it. If you're unwinding the stack aren't you going to be referring to DWARF tables anyway for things like symbols, CFI to locate catch blocks (in C++), or something else that is actually going to allow you to do something useful? Having to switch off of the instruction pointer to decode the stack doesn't seem like much of an extra burden. Just dumping a list of stack frame addresses isn't terribly useful. On another note, the DWARF standard is fairly approachable reading: http://dwarfstd.org/doc/DWARF4.pdf http://dwarfstd.org/doc/DWARF4.pdf
- boulos 12y agoYou can offer quite a lot of info (like backtraces, sampling profilers, etc.) for many runtimes just with the function name (which you can do without full on DWARF). The old LLVM JIT engine had a good NotifyFunctionEmitted hook for exactly this kind of usage. It's really about taking DWARF parsing / loading off the critical path for common use cases.