Platform/JSDebugv2: Difference between revisions

<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

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.

JS_ExecuteScript use copies of JSScripts owned by globals other than the

one passed to it.

<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

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

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.

These lists should include only those scripts in use by the page or

origin being debugged.

<dt>Draft C++ <span>js::dbg2</span> 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

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

breakpoint location objects, not scripts, and have entries cleaned up as

appropriate.

<dt>Implement <span>js::dbg2::Breakpoint</span><i>(15 days)</i>

<dd>Implement the js::dbg2::Breakpoint class, including insertion and

removal. This entails:

in functions that have JM frames on the stack

</ul>

</dl>