From MozillaWiki
Jump to: navigation, search

Spheres of debugging

js::dbg2::Sphere is an abstract base class representing "the thing being debugged" in the js::dbg2 interface. A sphere's job is to recognize events of interest and dispatch them to handlers. The types of spheres available depend on the application: a browser will have spheres representing things like:

  • a tab's top-level browsing context
  • a tab's top-level browsing context, and any descendant browsing contexts
  • all the scripts that run from, and the network interaction with, a given site within a given tab
  • a worker thread

The debug server consults application-specific facilities to enumerate the debugging spheres available; js::dbg2 provides only a few simple spheres whose semantics depend only on the JavaScript language itself.

High-level Source Positions

The js::dbg2 interface allows the debugger to specify breakpoint positions in terms of script URLs and line numbers, or function names qualified by enclosing scopes, rather than JSScript objects and bytecode offsets. js::dbg2 manages the mapping between source locations and trapped bytecodes, and inserts and removes trap bytecodes as JSScript objects are created and destroyed.

Code passed to 'eval' or the 'Function' constructors, or established via DOM manipulation, is assigned synthetic names; see also "Script Labeling", below.

The jsd interface for setting breakpoints requires the debugger to identify the jsdIScript (a wrapper for JSAPI JSScript objects) and bytecode offset within that script at which the breakpoint should be inserted. The debugger is responsible for tracking the creation and destruction of scripts, mapping source locations to (script, bytecode offset) pairs, and inserting and removing trap points. There are a number of problems with this approach:

  • The script+offset interface is oriented towards one particular implementation of JavaScript, out of the three we now have. js::dbg2's interface for breakpoint specification is implementation-neutral, as it expresses locations strictly in terms of JavaScript source code.
  • Tracking the creation and destruction of scripts is a source of considerable complexity in the debugger; being able to take advantage of SpiderMonkey's own data structures for managing JSScripts, which may need some revisions, is a net simplification.
  • If a bug in the debugger causes it to supply an incorrect location for a breakpoint trap bytecode, the debugger can cause the interpreter to crash. (At the moment, the system does not even check that the trap locations provided by the debugger are valid offsets into the script's bytecode, but that could easily be fixed.)
  • For remote debugging, it would be inefficient to report the creation and destruction of all JSScripts across the communication channel to the debugger. The js::dbg2 interface allows breakpoint re-setting to be handled locally.