GNOME Bugzilla – Bug 787573
Rebase and consolidate all debugger implementations
Last modified: 2018-01-27 12:05:45 UTC
Here are the various implementations of a debugger that are floating around: - Sam Spilsbury's, bug 744099 - Joe Shaw's, bug 619712 - Slawomir Wojtasiak's patch on a GitHub fork, https://github.com/swojtasiak/gjs/commit/391de095ec5345af0b95c8f7586b09a15037da66 - The debugger that goes with the SpiderMonkey shell, http://searchfox.org/mozilla-central/source/js/examples/jorendb.js For each of these I'll rebase it on / integrate it into modern GJS, and note the pros and cons of each one. Then, I'll come up with an implementation that combines the best of each. The end result should at least be usable in Builder and in a command-line client. Ideally it should also be usable via the Chrome / Firefox dev tools.
Created attachment 359577 [details] [review] Sam's Debugger Prototype
*** Bug 744099 has been marked as a duplicate of this bug. ***
This patch requires bug 777724, by the way.
Created attachment 359900 [details] [review] Joe's Debugger Prototype (does not compile) The debugger is integrated into the gjs runtime, and exposes a simple line protocol interface over a TCP socket (port 5580 by default). The network-facing parts run entirely in their own thread, with their own GMainContext and main loop. This means that interacting with the debugger is totally independent of the main thread executing JS, will never block, and doesn't require a gjs main loop to be running. With the debugger you can set and delete breakpoints based on line number, suspend and resume execution of the runtime, step through code line by line, view stack traces, examine local variables at any stack frame, and evaluate code at any stack frame. The debugger also supports the "debugger" JavaScript statement, and runtime execution will suspend just as if a breakpoint where hit when it comes across one of these. This is an incredibly helpful feature. Being a simple protocol on the socket, you can interact with it directly (as there are no clients yet, see below). I typically do so with "rlwrap nc localhost 5580". Here are the commands: break <file> <line> - create a breakpoint delete <file> <line> - delete a breakpoint stop - suspends execution of the runtime ASAP continue - resume execution of the runtime immediately step - steps through a line of code next - steps over a line of code finish - finishes executing the current stack frame stack - prints the current stack trace locals [frame] - prints local variables at the current or given stack frame eval [frame] <expr> - evaluates an expression at the current or given stack frame status - prints whether the runtime is running or suspended Output from these commands should be self-explanatory. One thing to note about this debugger is that it is a "soft" debugger that runs entirely in the context of the spidermonkey runtime. There is no ptrace support, and no support for debugging native code. However, this debugger should work well in tandem with gdb if you need to debug native code. This also means that if you attempt to get a stack trace while in native code (like, the glib main loop) you will simply get an empty stack trace. You can still evaluate code, but it'll run in the global context. If you try to suspend execution (with the "stop" command) it can only do so the next time JS code is executed. In general, to use the debugger in gjs projects you can either pass --debugger to gjs-console, or call gjs_context_start_debugger() if you are running the gjs runtime yourself.
This is a half-rebased version of Joe's debugger implementation, but it is not going to work, it depends too much on SpiderMonkey's old debug API. However, we may be able to steal some of the concepts from this patch, so it is useful to keep the patch around for reference.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gjs/issues/110.