3 ms·
It's very similar, but they wouldn't be able to "just use DWARF". Half the DWARF tables are devoted to byte sizes and where variables are stored in stack frame
by openasocket 9y ago
It's very similar, but they wouldn't be able to "just use DWARF". Half the DWARF tables are devoted to byte sizes and where variables are stored in stack frame offsets or registers. It's not like you could fork libdwarf or whatever and magically get JS debugging, the effort required to change to the different scenario is enough that it's not worth the effort.
- the_mitsuhiko 9y agoI'm not so sure. I looked precisely into this (using DWARF for JavaScript) and the changes to make DWARF work in that environment are not any crazier than fixing sourcemaps. As it stands sourcemaps are pretty much useless for a wide range of issues that we have with them and attempts to fix them went nowhere.
- laichzeit0 9y agoHonest question, will any of this matter once we've gone full WASM? Will DWARF be a good option then? As I understand in the not too distant future, everyone that absolutely despises Javascript and the whole ecosystem it re-invented will be able to merrily go about their way using the old familiar tools and languages from yore when they can compile to wasm.
- johncolanduoni 9y agoThere's some significant complications, like the fact that most languages that compile to WebAssembly will need to use two stacks at certain times (including C/C++). In this respect WASM is in a similar situation to .NET and the JVM, which use their own debugging information formats for good reason. Considering this wouldn't make much of a dent in the work needed to get tools like gdb/lldb to work with WebAssembly engines I don't think it's likely to be the best path forward for WASM.