Debugger feature: add backtrace command

[bobrippling]

I'd like to be able to see the call stack (useful for debugging what's called code, such as finding out where a width has been set), like bt in gdb - before I work on the feature though, is this something that would be accepted into espruino?

I'm thinking something like:

debug>bt
Frame 0: drawIcon(), "clock.js", line 5
Frame 1: draw(), "clock.js", line 20
Frame 2: anonymous, "clock.js", ...

[gfwilliams]

Well, if this were possible in an efficient way I'd be all for it. However if it were easy I'd have added it to the debugger already :)

Basically I don't want to calculate/store a bunch of extra stuff for each function call, because that would slow execution down.

So I guess you have two options really:

• Actually skip back down the stack (this will be platform dependent) a bit like GDB's bt would do, and find instances of jspeFunctionCall
• Add an oldLex pointer to JsLex, and as we replace it when we're executing the function (

  Espruino/src/jsparse.c

  Line 840 in 176a23c

  JsLex *oldLex = jslSetLex(&newLex);

  ) link in the 'old' lexer rather than storing it in JsLex *oldLex. That way the debugger could skip back down all the lexers and reconstruct the call stack.

Now I think about it the second option should be possible with minimal extra overhead

[bobrippling]

Interesting - I'll take a look, thanks for the pointers

[gfwilliams]

I've just fixed this. It actually worked really nicely linking back on the stack, and meant I could avoid some of the previous hackiness for stack traces. For instance you can now do (new Error()).stack and get a proper stack trace in your code at the point you call it. console.trace() also displays a stack trace too.

I've taken the opportunity to allow the stack trace to tag previously untraceable stuff too (for example when running code from .boot0 or the REPL), and I fixed the Uncaught undefined issue if there was a bug in app.boot.js

[SimonGAndrews]

Looks really useful thanks.

[bobrippling]

Great, thanks!