Remote Debugging Protocol: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Rename page to Remote Debugging Protocol; the full protocol documentation will be here.)
 
(bold)
 
(116 intermediate revisions by 9 users not shown)
Line 1: Line 1:
Mozilla will support remote debugging with a JSON-based protocol, roughly modeled after the [http://code.google.com/p/v8/wiki/DebuggerProtocol V8 Debugger Protocol].
This page moved to the mozilla-central repository with [https://bugzilla.mozilla.org/show_bug.cgi?id=1354587 bug 1354587].


The remote protocol operates at the JavaScript level, not at the C++ or
Read it now at '''https://docs.firefox-dev.tools/backend/protocol.html'''.
machine level. It assumes that the JavaScript implementation itself is
healthy and responsive: the JavaScript program being executed may have gone
wrong, but the JavaScript implementation's internal state must not be
corrupt. Bugs in the implementation may cause the debugger to fail; bugs in
the interpreted program must not.


= Debugging States =
Source code, at http://searchfox.org/mozilla-central/source/devtools/docs/backend/protocol.md
 
When a debugger client first makes a connection to a Mozilla process, no
debugging sphere has yet been selected, and the server uses the js::dbg2
sphere discovery facilities to answer client requests about what is
available to be debugged in that process:
 
[[File:Initial-connection.png]]
 
Selecting a debugging sphere establishes event handlers which invoke the
debug server to communicate the news to the debugger. Assuming the selected
sphere runs on the main thread, the stack looks like this while the event
is being reported:
 
[[File:main-thread-event.png]]
 
When the debugger asks the debuggee to continue, the frames for the
js::dbg2 dispatch facilities simply return, and the code that generated the
event resumes execution.
 
If the user asks the debugger to evaluate an expression that requires
evaluating JavaScript code (like <tt>e.x()</tt>), then that evaluation
takes place without leaving the dynamic scope of the trap handlers, but in
the static scope in which the event was generated, using js::dbg2's
evaluateInFrame facility:
 
[[File:Expression-evaluation.png]]
 
If evaluation of the expression throws an exception or hits a breakpoint,
then the result is a matter of user interface. Either we abandon evaluation
of the expression, and control returns to the original debug protocol
server frames, or we treat the event as something to be investigated, just
as if it had occurred in the debuggee's normal course of execution,
resulting in a nested debug server invocation:
 
[[File:Expression-nested-exception.png]]
 
If the debugger elects to debug a worker thread, the main thread acts as a
proxy, relaying messages to the worker thread's server:
 
[[File:worker-thread-event.png]]
 
(I am not sure whether we want to keep things this way, or have the
debugger connect directly to its debuggees. Being able to debug many
threads with a single socket connection seems like a win, and we still get
the inter-thread synchronization benefits; but latency might affect the
debuggers' users' experience. Let's code it and see!)
 
If Mozilla puts content and chrome in separate processes, then the remote
protocol can be readily used to continue to support content debugging:
 
[[File:content-process.png]]

Latest revision as of 05:22, 12 January 2019

This page moved to the mozilla-central repository with bug 1354587.

Read it now at https://docs.firefox-dev.tools/backend/protocol.html.

Source code, at http://searchfox.org/mozilla-central/source/devtools/docs/backend/protocol.md

Retrieved from "https://wiki.allizom.org/index.php?title=Remote_Debugging_Protocol&oldid=1206107"