Advanced debugger features

[zherczeg]

I think the core debugger features are completed. The list of these features follows:

Breakpoint management:

• Sending source code and breakpoint info
• Enabling / disabling breakpoints

Execution control:

• step-in
• next
• continue
• stop execution

Other features:

• evaluating expressions
• getting backtrace
• getting scope chain
• getting variables of a lexical environment

Could you tell us what other features do you need? I can share some ideas. These ideas requires shell support (environment outside of Escargot engine), so porting them to other environments require some effort.

Source sending feature: instead of executing a js file, the shell enters to a "wait for source code" mode. After the debugger sends the source code, the shell executes it. This is useful for trying JS code without flashing it onto a device, and also useful for demonstration purposes.

Restarting feature: allow the debugger to restart the JavaScript code. This is a difficult feature (for the environment, not for the debugger), since the current execution must be aborted, all resources must be freed, and a new Escargot instance must be created.

Debug log support: most environments have a "print" or "console.log" native function, which displays some text. However, if the device has no screen, this output can be lost. Sending this output to the debugger is useful in this case, since it can also display this output.

[clover2123]

Thank you very much for your wonderful contribution:)

Yes, we definitely have to support environment outside of Escargot engine.
All your ideas looks great!

BTW I have some questions/requests as follows.

• With current features, is it enough to intergrate with IDE tools like VSCode?
• How about adding "kill" option which immediatly ends the debugger run?
• Turning on/off the debugger during the runtime is one of possible scenarios?
  If it is possible there would be cases that we should support such as generating/freeing bytecode during the runtime or other things (it seems that the most part of debugger module already checks the status of debugger before executing debugging operation).
• Handling errors/segfaults
  Escargot throws an exception for each error case. There might be segfaults for undesirable internal errors too. IMO The debugger needs to catch these errors and pass the status especially for shell support.

[zherczeg]

Hi,

• Yes, we already have a working VSCode debugger prototype now, but we can work on more features (e.g. restart), and can make the extension more user friendly
• Kill the JS execution or just detach the debugger? Detach is very simple operation. If we want to kill the JS execution, we need to figure out a way to do it. Perhaps throwing some kind of abort (which is not caught by try/catch(Value) C++ handlers) could work. Do you have a better suggestion?
• Even if the debugger is enabled, you can run the code without debugger (that is why there are checks). The debugger client can also detach from the process, and the code runs without debugger afterwards. However, the debugger cannot attach, because the breakpoints must be inserted into the byte-code, and I think the currently executing code cannot be replaced. Example:

function f() {
  a++;
  b++;
}

If we would attach when a++ is executed, we cannot change the byte code of f because the byte code of the function is currently executed by the vm (it has a pointer to the byte code, and an offset to the current instruction, and even worse, if computed gotos are enabled, we have a direct pointer to the instruction). Those things should be updated in some way. If you have a good solution maybe we could try to support this use case.

• Could you explain what should exactly happen? Shall we install signal handlers to capture segfaults and send a notification to the debugger client? Shall we insert a notification before every throw c++ statement in the code? Or just report them when a JS catch caughts them? What would be the status?

[clover2123]

• adding "kill" or "quit" option
  IMO detaching(finishing) the debugger would be enough.

• Turning on/off the debugger during the runtime
  I'm wondering that this is one of common features in other JS debuggers. As you mentioned, replacing the bytecode during the code execution is extremely difficult. If we don't need to support this case, just ignore it.

• Handling errors/segfaults
  IMO printing each exception error message is useful for debugging (for segfault case, just finishing the debugging would be enough). When an exception occurs Escargot prints an error message with JS call stack infos. But the debugger client just quits its run. How about supporting exception messages in the debugger client too? To be specific, when an exception occur, ErrorObject with error message is generated and thrown which is then catched in SandBox::run. Sandbox also calculates stack tracing data to provide JS call stack infos. We may deliver these exception-releated infos to the debugger as well.

[zherczeg]

Regarding on/off the debugger: the debugger can work silently. If no breakpoints are set, and no stop command is issued, the program just runs. So the IDE can simulate attach / detach / attach again events by temporariliy enabling and disabling breakpoints.

Regarding errors: am I understand correctly, that we just need to notify users, but does not need to do any actions? Sending this data is not difficult.

[clover2123]

I missed that "quit" option was already added
Regarding errors: yes, just notify the users.

"finish" option looks similar to "until" option in gdb. Is this also one of essential features in JS debugger?

[zherczeg]

"finish" is a command in gdb, and VSCode debugger has a "step-out" command which is the same:
https://sourceware.org/gdb/onlinedocs/gdb/Continuing-and-Stepping.html
https://code.visualstudio.com/docs/editor/debugging#_debug-actions

I don't think this is essential, so if you want it I can close #618 .

[zherczeg]

Btw the VSCode command mapping will look like this (left VSCode, right Escargot debugger):

Continue / Pause - ESCARGOT_MESSAGE_CONTINUE / ESCARGOT_MESSAGE_STEP
Step Over - ESCARGOT_MESSAGE_NEXT
Step Into - ESCARGOT_MESSAGE_STEP
Step Out - ESCARGOT_MESSAGE_FINISH
Restart - not implemented yet
Stop - closing socket

[clover2123]

Thanks for your detailed explanation.
It seems that we should add "finish" command to support "Step out" in VSCode.