I agree that inspecting the stack is different than inspecting the heap; the Chrome proposal doesn't cover that. But we could come up with a similar API allowing the debugger to pass in a representation of the JavaScript stack to a stack deobfuscator and get back a language-specific representation of the stack for display; it's basically the same thing. (A complication: when a program is written in multiple languages that call each other, we need to figure out which language each portion of the stack belongs to.) Stack frames are often not one-to-one either due to inlining and variable reuse, but for a given stack frame and a given location in the source code, there will be some interpretation of the JavaScript stack frame that makes sense.
The idea is that the reflection library has all the language-specific knowledge baked in, because a compiler generates a different .js file containing debugging information for each program, just as it generates a source map today.
More generally, any information sent as a data file can just as easily be sent as a JavaScript file if we can come up with a suitable API. A data format will in general be less flexible than one that includes the possibility of running code.
Scopes are tree-shaped, what more flexibility do you need? Do you have a reason to believe that DWARF, which has stood the test of time, is somehow lacking in this regard? Don't forget that unnecessary flexibility is really just needless complexity. As the article says, the final mapping from a debugger entry to a value can be performed using JavaScript in order to have flexibility where it is actually needed.
Any API which inspects the stack is (obviously) going to have to run in a separate thread/stack which then means you won't be able to use plain JavaScript to retrieve in-scope object values, as in the article. Instead you'll have to introduce an API which provides a means to reflect over the other thread/stack's scope tree - so the "less flexible" scope tree will simply be baked in to your (by this point very complex) API.
I'm not that familiar with DWARF, but its support for languages that aren't C seems to be limited. Go apparently emits DWARF information [1] but it's regarded as a language that doesn't have good debugger support - for example, see [2]. Apparently Haskell (ghc) has some support but it's pretty limited? [3]
It's not used at all for Hotspot, V8, or Dart. The way these languages work is that they have a debugger protocol that allows the debugger to connect to the runtime system. That isn't so far from providing a debugging library written in JavaScript.
So I think if DWARF can work, it needs to be proven.
Its easier and cheaper to both write and interpret a pure data api.
A pure data api is going to be more easily compressible, more performant, and easier to specify (since execution state or time never enters into the picture).
It also avoids a lot of issues with your proposal, like multiple passes (do you need to run it through multiple functions? this is getting more complicated, not to mention even slower...), multiple languages (which you mentioned, but is really only an issue caused by your suggestion...)
You'll have to explain how to do it with a pure data format because I don't see how. It seems like a data format will only work for languages with a similar implementation to what the designers of the format had in mind?
As a simple example, how do you determine the type of a JavaScript object on the heap when each language implements runtime type tags differently, and each language has a different type system?
A language-specific JavaScript function running in the same heap can do whatever it likes to compute the type, including calling into the language's runtime system. Furthermore, the Chrome API I linked to doesn't even care what the type system is; all it cares is that the data can be somehow displayed in outline format.
Of course, this approach has its limitations too; it does assume that, at least at the top level of the outline, you start with a JavaScript object and there's some way to compute a runtime type from it. This doesn't work for an untagged language where we refer to objects using array indexes like with asm.js. So it's not completely general. But I think that just means the design needs improvement; I don't see how switching to a pure data format would help.
Comments
I agree that inspecting the stack is different than inspecting the heap; the Chrome proposal doesn't cover that. But we could come up with a similar API allowing the debugger to pass in a representation of the JavaScript stack to a stack deobfuscator and get back a language-specific representation of the stack for display; it's basically the same thing. (A complication: when a program is written in multiple languages that call each other, we need to figure out which language each portion of the stack belongs to.) Stack frames are often not one-to-one either due to inlining and variable reuse, but for a given stack frame and a given location in the source code, there will be some interpretation of the JavaScript stack frame that makes sense.
The idea is that the reflection library has all the language-specific knowledge baked in, because a compiler generates a different .js file containing debugging information for each program, just as it generates a source map today.
More generally, any information sent as a data file can just as easily be sent as a JavaScript file if we can come up with a suitable API. A data format will in general be less flexible than one that includes the possibility of running code.
Scopes are tree-shaped, what more flexibility do you need? Do you have a reason to believe that DWARF, which has stood the test of time, is somehow lacking in this regard? Don't forget that unnecessary flexibility is really just needless complexity. As the article says, the final mapping from a debugger entry to a value can be performed using JavaScript in order to have flexibility where it is actually needed.
Any API which inspects the stack is (obviously) going to have to run in a separate thread/stack which then means you won't be able to use plain JavaScript to retrieve in-scope object values, as in the article. Instead you'll have to introduce an API which provides a means to reflect over the other thread/stack's scope tree - so the "less flexible" scope tree will simply be baked in to your (by this point very complex) API.
I'm not that familiar with DWARF, but its support for languages that aren't C seems to be limited. Go apparently emits DWARF information [1] but it's regarded as a language that doesn't have good debugger support - for example, see [2]. Apparently Haskell (ghc) has some support but it's pretty limited? [3]
It's not used at all for Hotspot, V8, or Dart. The way these languages work is that they have a debugger protocol that allows the debugger to connect to the runtime system. That isn't so far from providing a debugging library written in JavaScript.
So I think if DWARF can work, it needs to be proven.
[1] http://blog.golang.org/debugging-go-code-status-report [2] http://www.reddit.com/r/golang/comments/2h57hf/trouble_debug... [3] https://ghc.haskell.org/trac/ghc/wiki/DWARF
Its easier and cheaper to both write and interpret a pure data api.
A pure data api is going to be more easily compressible, more performant, and easier to specify (since execution state or time never enters into the picture).
It also avoids a lot of issues with your proposal, like multiple passes (do you need to run it through multiple functions? this is getting more complicated, not to mention even slower...), multiple languages (which you mentioned, but is really only an issue caused by your suggestion...)
You'll have to explain how to do it with a pure data format because I don't see how. It seems like a data format will only work for languages with a similar implementation to what the designers of the format had in mind?
As a simple example, how do you determine the type of a JavaScript object on the heap when each language implements runtime type tags differently, and each language has a different type system?
A language-specific JavaScript function running in the same heap can do whatever it likes to compute the type, including calling into the language's runtime system. Furthermore, the Chrome API I linked to doesn't even care what the type system is; all it cares is that the data can be somehow displayed in outline format.
Of course, this approach has its limitations too; it does assume that, at least at the top level of the outline, you start with a JavaScript object and there's some way to compute a runtime type from it. This doesn't work for an untagged language where we refer to objects using array indexes like with asm.js. So it's not completely general. But I think that just means the design needs improvement; I don't see how switching to a pure data format would help.