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.
Comments
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