Confirmed users
496
edits
Platform/JSDebugv2: Difference between revisions
Jump to navigation
Jump to search
→Estimates
(Move "High-level source positions" and "Remote Debugging" to top of list, as they relate more directly to the goals) |
|||
| Line 111: | Line 111: | ||
* For remote debugging, it would be very inefficient to report the creation and destruction of all JSScripts across the communication channel to the debugger. | * For remote debugging, it would be very inefficient to report the creation and destruction of all JSScripts across the communication channel to the debugger. | ||
=== Estimates === | === Tasks and Estimates === | ||
Note that all estimates include time to write unit tests | Note that all estimates include time to write unit tests | ||
providing full code and branch coverage for new code. | providing full code and branch coverage for new code. | ||
<dl> | <dl> | ||
<dt>JS_CopyScript JSAPI function <i>(8 days)</i> | <dt>JS_CopyScript JSAPI function <i>(8 days)</i> | ||
| Line 121: | Line 119: | ||
of a JSScript object, suitable for execution in a thread or global object | of a JSScript object, suitable for execution in a thread or global object | ||
different than the original JSScript. | different than the original JSScript. | ||
<p>For various reasons, SpiderMonkey is moving towards restricting each | |||
For various reasons, SpiderMonkey is moving towards restricting each | |||
JSScript to be used with a single global object (the next task; see details | JSScript to be used with a single global object (the next task; see details | ||
there). Before we can impose this requirement, we must make it possible for | there). Before we can impose this requirement, we must make it possible for | ||
embedders to comply with it by providing a function which copies a JSScript | embedders to comply with it by providing a function which copies a JSScript | ||
object. | object.</p> | ||
<dt>Associate JSScripts with specific global objects <i>(5 days)</i> | <dt>Associate JSScripts with specific global objects <i>(5 days)</i> | ||
<dd>Add a 'global' field to JSScript, and change JS_ExecuteScript to clone | <dd>Add a 'global' field to JSScript, and change JS_ExecuteScript to clone | ||
JSScript objects if necessary to match the global object passed. | JSScript objects if necessary to match the global object passed. | ||
<p>This is needed to allow us to enumerate all the scripts in use by a | |||
This is needed to allow us to enumerate all the scripts in use by a | |||
particular global object, along with several other current SpiderMonkey | particular global object, along with several other current SpiderMonkey | ||
goals; see {{bug|563375#c4}}. We can accomplish this by having | goals; see {{bug|563375#c4}}. We can accomplish this by having | ||
JS_ExecuteScript use copies of JSScripts owned by globals other than the | JS_ExecuteScript use copies of JSScripts owned by globals other than the | ||
one passed to it. | one passed to it.</p> | ||
<dt>Change <span>JSRuntime::scriptFilenameTable</span> to use <span>js::HashMap</span> <i>(3 days)</i> | <dt>Change <span>JSRuntime::scriptFilenameTable</span> to use | ||
<span>js::HashMap</span> <i>(3 days)</i> | |||
<dd>Since subsequent tasks will involve changing the data structures used | <dd>Since subsequent tasks will involve changing the data structures used | ||
to store script source URLs, we should grant ourselves the benefits of | to store script source URLs, we should grant ourselves the benefits of | ||
| Line 149: | Line 146: | ||
<dd>Define a function to enumerate the URLs of all scripts associated | <dd>Define a function to enumerate the URLs of all scripts associated | ||
with a given global object. | with a given global object. | ||
<p>Debugger user interfaces need to be able to present the user with | |||
Debugger user interfaces need to be able to present the user with | |||
a list of the scripts in use by a particular page or origin, so that | a list of the scripts in use by a particular page or origin, so that | ||
the user can browse their source code, set breakpoints, and so on. | the user can browse their source code, set breakpoints, and so on. | ||
These lists should include only those scripts in use by the page or | These lists should include only those scripts in use by the page or | ||
origin being debugged. | origin being debugged.</p> | ||
<dt>Draft C++ <span>js::dbg2</span> breakpoint API <i>(3 days)</i> | <dt>Draft C++ <span>js::dbg2</span> breakpoint API <i>(3 days)</i> | ||
<dd>Write a C++ API declaring: | <dd>Write a C++ API declaring: | ||
| Line 162: | Line 158: | ||
of function names (a global object, a series of containing function names, | of function names (a global object, a series of containing function names, | ||
and a final function name), or in terms of specific function objects. | and a final function name), or in terms of specific function objects. | ||
<p>The API should permit the "grammar" of breakpoint locations to be | |||
The API should permit the "grammar" of breakpoint locations to be | |||
extended in the future (to describe, say, function-valued properties in | extended in the future (to describe, say, function-valued properties in | ||
object literals). | object literals).</p> | ||
<p>These should be designed such that, in normal, efficent use, no explicit | |||
These should be designed such that, in normal, efficent use, no explicit | storage management (new/delete) is required.</p> | ||
storage management (new/delete) is required. | <p>URLs in breakpoint locations should be represented as entries in the | ||
URLs in breakpoint locations should be represented as entries in the | |||
runtime's scriptFilenameTable. This means that, given a breakpoint | runtime's scriptFilenameTable. This means that, given a breakpoint | ||
location, we have immediate access to the list of JSScripts derived from | location, we have immediate access to the list of JSScripts derived from | ||
the source code to which the location refers. | the source code to which the location refers.</p> | ||
<p>If possible, the URL/line/column variant of this type should be suitable | |||
If possible, the URL/line/column variant of this type should be suitable | |||
for use by the js::dbg2 stack frame type to represent source positions; we | for use by the js::dbg2 stack frame type to represent source positions; we | ||
should not need two distinct types that represent locations in source code. | should not need two distinct types that represent locations in source code.</p> | ||
<li>A class representing a breakpoint, js::dbg2::Breakpoint, which can be | <li>A class representing a breakpoint, js::dbg2::Breakpoint, which can be | ||
inserted in or removed from a debugging sphere. This API will not be | inserted in or removed from a debugging sphere. This API will not be | ||
| Line 205: | Line 197: | ||
in functions that have JM frames on the stack | in functions that have JM frames on the stack | ||
</ul> | </ul> | ||
<dt>Use function start positions when re-setting breakpoints <i>(8 days)</i> | |||
<dd>When re-loading a previously loaded script, we should use our knowledge | |||
of function boundaries to improve our accuracy as we re-set breakpoints in | |||
the new script. If all changes to a script lie outside a given function's | |||
definition, then treating the breakpoint as if it were set relative to the | |||
function's start, rather than at an absolute line and column, will allow us | |||
to find a better location for it in the new script. | |||
<dt>Expand source notes to carry column information <i>(8 days)</i> | |||
<dd>Extend the source notes attached to JSScripts to carry both line and | |||
column information. This allows debugging of poorly-formatted code such as | |||
that produced by script compressors or obfuscators. The bytecode compiler | |||
already tracks column numbers; they're simply not recorded in the source | |||
notes. | |||
<p>Note that this need not imply any increase in the size of notes for | |||
normally formatted source code: the granularity of the features | |||
distinguished by the source annotations (that is, statements) need not | |||
change. Only if there were multiple statements or functions on the same | |||
line would column numbers be needed to distinguish them.</p> | |||
</dl> | </dl> | ||