4 ms·
What poor choices are revealed by writing a debugger in particular? At this point, he compiles Jai to C, and the compiler isn't too gigantic yet, so there's no
by cheepin 11y ago
What poor choices are revealed by writing a debugger in particular?
At this point, he compiles Jai to C, and the compiler isn't too gigantic yet, so there's not a huge surface area to look for compiler bugs.
- humanrebar 11y ago> What poor choices are revealed by writing a debugger in particular? Well, for one, you can't just transpile to ANSI C, compile, and end up with sensible debug symbols in your binary. You'll end up with debug symbols for the C code, not the original language. So you end up writing in one language and debugging in another. This is one reason most new languages target LLVM.
- sanxiyn 11y agoCompiling to C with #line directive actually gives a good enough debugging experience, similar to compiling to JavaScript with source map. This is much easier than generating debug info, even with LLVM.
- pcwalton 11y agoI don't think it's good enough. You can't inspect variables, types will be wrong, any namespacing you're doing will leak into the debugger, single step won't give you the right semantics unless your language is extremely close to C, gdb pretty printing won't know how to print your language's values, etc. Backtraces will sort of work (although the name mangling will leak through), but little else will. You really need to generate DWARF directly in your frontend in order to have an acceptable debugging experience.
- scott_karana 11y ago> Well, for one, you can't just transpile to ANSI C, compile, and end up with sensible debug symbols in your binary Doesn't that depend entirely on how similar your language is to C? ;)
- drdeca 11y agoDoesn't it currently have a compile to c, and a to byte code? (which allows for compile time run of things)