debugger: add external command to control ShadowNode

[algebrait]

• Version: 0.9.x
• Platform: all
• Subsystem:

Add a standalone program, say sncmd. sncmd can send control commands to ShadowNode, such as print stack, start/stop CPU profiler, dump heap, dump memory info, dump net info, etc. Then it is easy to write various powerful scripts based on it. Possible implementations: 1) sncmd use sigqueue to send signal, and shadownode use sigaction to receive signal, 2) use socket

[algebrait]

Seems jerryscript debugger is enough. Work to do is to extend it's protocol.

[yorkie]

Should we change the debugger protocol to chrome's?

[algebrait]

Pros and cons of using debugger and signal debugger: jerry already has a debugger. The only thing to do is to extend it. And any data structure can be sent. But the jerry/shadownode should explicitly add command line param --start-debug-server and --debug-port NUM which is perhaps not acceptable for OS testing. signal: The signal impl is only a signal action. It is not needed to manage life cycle of communications. It's not easy for signal to send complicated data structure. And it seems MacOS does not support sigqueue.

[algebrait]

This issue is to integrate our new tools. The whole chrome debugger protocol should be discussed in other issue.

[yorkie]

The whole chrome debugger protocol should be discussed in other issue.

They have no direct reference but relevant. We now have in total 2 ways to work with the real world:

• JerryScript Debugger in WebSocket.
• tmpfile() by our profilers.

These make chaos on this part already, so that's why I persists on cleaning this up at first. In ideal, all the debug features(debugger/performance/heapdump) should be looked as the Node.js and Chrome have done. Therefore we should integrate these actions with WebSocket protocols. This is for GUI users.

Otherwise, ShadowNode did have a plan for command-line tool(#159), that's lldb-node or gdb-node, then adding commands such heapdump and perf is free to have done in that way.

[yorkie]

But the jerry/shadownode should explicitly add command line param --start-debug-server and --debug-port NUM which is perhaps not acceptable for OS testing.

Yea, their purposes are different, the debugger is for debugging. We should declare explicitly another way for testing. A global environment variable maybe a good argument to turn that on.

[algebrait]

Interactive tools such as debugger is not convenience to build auto test tools. The requirement is to send vm some command, but not to open a debugger.

[algebrait]

After some discussion with @yorkie @legendecas, we would like such solution:

1. Use sigqueue and sigaction to notify ShadowNode control commands.
2. Do not support MacOS if solution not found.
3. The sigaction is only a channel. All control commands will be sent to a JS module. Such mechanism will keep interpreting logic scalable and dynamic.