Confirmed users
496
edits
Platform/JSDebugv2: Difference between revisions
→High-level Source Positions
| Line 79: | Line 79: | ||
It will be the responsibility of js::dbg2 to manage the mapping between | It will be the responsibility of js::dbg2 to manage the mapping between | ||
source locations and trapped bytecodes, and insert and remove trap | source locations and trapped bytecodes, and insert and remove trap | ||
bytecodes as | bytecodes as JSScript objects are created and destroyed. | ||
Code passed to 'eval' or the 'Function' constructors, or established via | Code passed to 'eval' or the 'Function' constructors, or established via | ||
| Line 100: | Line 100: | ||
* 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 == | |||
Note that all estimates include time to write unit tests | |||
providing full code and branch coverage for new code. | |||
<dl> | |||
<dt>JS_CopyScript JSAPI function <i>(8 days)</i> | |||
<dd>Implement, document, and test a function that makes a fresh, deep copy | |||
of a JSScript object, suitable for execution in a thread or global object | |||
different than the original JSScript. | |||
<p>For various reasons, SpiderMonkey is moving towards restricting each | |||
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 | |||
embedders to comply with it by providing a function which copies a JSScript | |||
object. | |||
<dt>Associate JSScripts with specific global objects <i>(5 days)</i> | |||
<dd>Add a 'global' field to JSScript, and change JS_ExecuteScript to clone | |||
JSScript objects if necessary to match the global object passed. | |||
This is needed to allow us to enumerate all the scripts in use by a | |||
particular global object, along with several other current SpiderMonkey | |||
goals; see {{bug|563375#c4}}. We can accomplish this by having | |||
JS_ExecuteScript use copies of JSScripts owned by globals other than the | |||
one passed to it. | |||
<dt>Change JSRuntime::scriptFilenameTable to use js::HashMap <i>(3 days)</i> | |||
<dd>Since subsequent tasks will involve changing the data structures used | |||
to store script source URLs, we should grant ourselves the benefits of | |||
strict typing provided by the new js::HashMap template. | |||
<dt>Create name-to-script mapping <i>(8 days)</i> | |||
<dd>Adapt the existing hash table of script names to also function as a | |||
map from script names to scripts. This entails adding links to | |||
JSScript objects, arranging for entries in scriptFilenameTable to | |||
head chains of scripts, and having garbage collection properly remove | |||
scripts from their names' lists. | |||
<dt>Script URL enumeration <i>(5 days)</i> | |||
<dd>Define a function to enumerate the URLs of all scripts associated | |||
with a given global object. | |||
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 | |||
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 | |||
origin being debugged. | |||
<dt>Draft C++ js::dbg2 breakpoint API <i>(3 days)</i> | |||
<dd>Write a C++ API declaring: | |||
<ul> | |||
<li>A class representing a position at which a breakpoint can be set, | |||
expressed in terms of textual positions (URL, line, and column) or in terms | |||
of function names (a global object, a series of containing function names, | |||
and a final function name), or in terms of specific function objects. | |||
The API should permit the "grammar" of breakpoint locations to be | |||
extended in the future (to describe, say, function-valued properties in | |||
object literals). | |||
These should be designed such that, in normal, efficent use, no explicit | |||
storage management (new/delete) is required. | |||
URLs in breakpoint locations should be represented as entries in the | |||
runtime's scriptFilenameTable. This means that, given a breakpoint | |||
location, we have immediate access to the list of JSScripts derived from | |||
the source code to which the location refers. | |||
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 | |||
should not need two distinct types that represent locations in source code. | |||
<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 | |||
concerned with breakpoint conditions, ignore counts, and such; those | |||
behaviors must be implemented by the client of the js::dbg2 interface. | |||
<li>A stub js::dbg2::Sphere class, sufficient for bootstrapping, | |||
constructed from a given global object. | |||
<li>Debugging sphere member functions for enumerating the currently | |||
inserted breakpoints. | |||
</ul> | |||
<dt>Implement Breakpoint Location Classes <i>(5 days)</i> | |||
<dd>Implement the classes described above describing breakpoint locations. | |||
There may be some tricky work here, as we want to have entries in the | |||
scriptFilenameTable that are live because they are referred to by | |||
breakpoint location objects, not scripts, and have entries cleaned up as | |||
appropriate. | |||
<dt>Implement js::dbg2::Breakpoint<i>(days and days)</i> | |||
<dd>Implement the js::dbg2::Breakpoint class, including insertion and | |||
removal. This entails: | |||
<ul> | |||
<li>turning the various sorts of breakpoint locations into JSScript,offset pairs | |||
<li>searching JSScript lists to insert and remove traps | |||
<li>managing multiple breakpoints set at the same bytecode | |||
<li>inserting traps for existing breakpoints into newly loaded code (pending breakpoints) | |||
<li>coping with scripts being garbage collected | |||
<li>interlocking with JägerMonkey to insure that breakpoints are never set | |||
in functions that have JM frames on the stack | |||
</ul> | |||
</dl> | |||
= New top-level heading okay? = | |||
Junk. | |||
= Remote Debugging = | = Remote Debugging = | ||