Platform/JSDebugv2: Difference between revisions

Debugger user interfaces communicate with the application being debugged via a [[Remote Debugging Protocol|remote debugging protocol]]. The protocol is JSON-based, with clients and servers typically implemented in JavaScript. The protocol is actor-oriented: each packet is directed to or received from a specific actor, representing a thread, breakpoint, JavaScript object, or the like.

Every server provides a root actor that can provide global information about the application ("I am a web browser"), and enumerate the potential debuggees present in the application—tabs, worker threads, chrome, and so on—each represented by its own actor.

 

 

The jsd2IDebuggerService Web IDL interface presents js::dbg2's facilities to JavaScript.  jsd2IDebuggerService is an alternative to the existing jsdIDebuggerService.

 

The js::dbg2 interface provides functions to:

 

* select code of interest to the developer (everything in a tab; a selected frame within a tab; chrome; and so on),

 

* establish breakpoints, watchpoints, and other sorts of monitoring, and be notified when events of interest occur,

 

* inspect and manipulate stack frames, scope chains, objects, and other such members of the JavaScript menagerie.

[[File:Architecture-new.png]]

=== Debugging Protocol ===

[[Remote Debugging Protocol|Remote debugging]], in which the debugger's user interface can run in a separate process from the debuggee and communicates with the debuggee over a stream connection, addresses many of our goals at once:

<li><b>A debugger running in a separate process from the debuggee is easier to make robust.</b> The debugger's user interface and the debuggee need not share an event loop or a chrome DOM tree.

<li><b>Remote debugging eases mobile development.</b> The debugger could run on a desktop computer, and operate on a debuggee on a mobile device.

<li><b>The remote protocol can handle almost all inter-thread communication.</b> Each actor runs on the same thread as the debuggee it represents, so actor/debuggee interactions are intra-thread, and need not worry about synchronization or shared state. Actors and the application's main server interact only by exchanging protocol packets. The debugger

user interface simply needs to be able to talk to more than one agent at a time.<p>(Note that some operations are inherently cross-thread: enumerating

=== The js::dbg2 Interfaces and jsd2IDebuggerService ===

The [[js::dbg2|js::dbg2 interfaces]], wrapped for JavaScript as the jsd2IDebuggerService, allow the debugger to select the code to debug, set breakpoints and watchpoints and otherwise express interest in debuggee

behaviors, and inspect the debuggee's state.

The js::dbg2 interfaces operate at a higher level than jsd. Whereas jsd works in terms of the original SpiderMonkey bytecode interpreter&mdash;JSScript objects, bytecode offsets, JSStackFrame objects, and so on&mdash;the js::dbg2 interfaces operate at the JavaScript source code and value level, and avoid referring to

Like jsd, js::dbg2 provides <i>grip</i> objects that refer to values in the

debuggee. The debugger can inspect the object's properties, their attributes, and so on via the grip without accidentally invoking getters or setters, making it easier to write secure and robust debuggers.

Also like jsd, js::dbg2 provides grip objects referring to JavaScript stack frames. However, there is no necessary correspondence between js::dbg2 stack frame grips and SpiderMonkey's internal JSStackFrame objects. SpiderMonkey's JITs are free to report the current function activations to js::dbg2 in whatever way is most convenient to them; they are not required to synthesize JSStackFrame objects, which must satisfy complex internal constraints.