Platform/JSDebugv2: Difference between revisions

Platform/JSDebugv2 (view source)

Revision as of 18:18, 11 May 2010

3 bytes removed , 11 May 2010

no edit summary

Sayrer

546

edits

@@ Line 74: / Line 74: @@
 </ul>
-= Strategy =
-= High-level Source Positions =
-The js::dbg2 interface will allow the debugger to specify breakpoint
-positions in terms of script URLs and line numbers, or function names
-qualified by enclosing scopes, not JSScript objects and bytecode offsets.
-It will be the responsibility of js::dbg2 to manage the mapping between
-source locations and trapped bytecodes, and insert and remove trap
-bytecodes as JSScript objects are created and destroyed.
-Code passed to 'eval' or the 'Function' constructors, or established via
-DOM manipulation, will be assigned synthetic names; see also "Script
-Labeling", below.
-The jsd interface for setting breakpoints requires the debugger to identify
+= Tasks and Estimates =
-the <tt>jsdIScript</tt> (a wrapper for JSAPI <tt>JSScript</tt> 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. The new 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, should be 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 very inefficient to report the creation and destruction of all JSScripts across the communication channel to the debugger.
-=== Tasks and Estimates ===
 Note that all estimates include time to write unit tests
 providing full code and branch coverage for new code.
@@ Line 210: / Line 180: @@
 line would column numbers be needed to distinguish them.</p>
 </dl>
+= Strategy =
+= High-level Source Positions =
+The js::dbg2 interface will allow the debugger to specify breakpoint
+positions in terms of script URLs and line numbers, or function names
+qualified by enclosing scopes, not JSScript objects and bytecode offsets.
+It will be the responsibility of js::dbg2 to manage the mapping between
+source locations and trapped bytecodes, and insert and remove trap
+bytecodes as JSScript objects are created and destroyed.
+Code passed to 'eval' or the 'Function' constructors, or established via
+DOM manipulation, will be assigned synthetic names; see also "Script
+Labeling", below.
+The jsd interface for setting breakpoints requires the debugger to identify
+the <tt>jsdIScript</tt> (a wrapper for JSAPI <tt>JSScript</tt> 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. The new 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, should be 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 very inefficient to report the creation and destruction of all JSScripts across the communication channel to the debugger.
 = Remote Debugging =