Confirmed users
496
edits
Platform/JSDebugv2: Difference between revisions
Jump to navigation
Jump to search
Move "High-level source positions" and "Remote Debugging" to top of list, as they relate more directly to the goals
(Move "High-level source positions" and "Remote Debugging" to top of list, as they relate more directly to the goals) |
|||
| Line 81: | Line 81: | ||
</ul> | </ul> | ||
= High-level Source Positions = | = High-level Source Positions = | ||
| Line 271: | Line 224: | ||
* We can use it to debug worker threads, simply by using an intra-process communications channel (and perhaps using the fact that we share the debuggee's architecture and ABI to use a simpler protocol). | * We can use it to debug worker threads, simply by using an intra-process communications channel (and perhaps using the fact that we share the debuggee's architecture and ABI to use a simpler protocol). | ||
= Event Handlers and Spheres = | |||
A JavaScript debugger connects to a debuggee by expressing to js::dbg2 its | |||
interest in <em>events</em> occurring in particular <em>spheres</em>. | |||
Events are things like breakpoint or watchpoint hits, completions of | |||
single-step operations, exceptions being thrown, or 'eval' being called. | |||
Spheres are things like particular global objects, origins (in the HTML5 | |||
sense), XUL chrome, worker threads, or other things that identify | |||
subdivisions of the system that one might want to select to debug. | |||
(In jsd, the <tt>jsdIFilter</tt> interface attempts to help the debugger | |||
distinguish the events it cares about from those it doesn't, but it bases | |||
its decisions on script URL patterns; the debugger user wants to debug a | |||
particular web site, which could use code from any number of sources. | |||
js::dbg2's filtering by origin (web site) and global (web page) provide a | |||
better basis for implementing the behavior the debugger's users actually | |||
want.) | |||
It may be helpful to provide events reporting the creation and destruction | |||
of spheres (creating new tabs; visiting new web sites); this is something I | |||
don't understand well yet. | |||
= Frames and Scopes = | |||
Like jsd, js::dbg2 represents the control stack as a list of frames. | |||
* A frame representing a call to a JavaScript function has a source location (a URL,line pair), and a scope (a set of identifier bindings). Given a scope, one can look up an identifier's binding, enumerate the bindings present, find its enclosing scope, evaluate JavaScript expressions in that scope, and so on. | |||
* A frame representing a call to a host function (implemented in C++, say) will have some appropriate identification. | |||
In this area, js::dbg2's behavior will not differ much from jsd's, except | |||
that it will identify the current point of execution using script URLs and | |||
line numbers, not a script proxy objects and bytecode offsets; see | |||
"High-level Source Positions", below. | |||
= Value Proxies = | |||
Like jsd, js::dbg2 does not permit the debugger to refer to values in the | |||
debuggee directly. Instead, it provides proxy objects (analogous to jsd's | |||
<tt>jsdIValue</tt>) which facilitate inspection, but protect the debugger | |||
from inadvertently invoking getters, setters, and the like. js::dbg2 will | |||
follow jsd's design here, except that the facilities for examining object | |||
properties will more closely resemble ES5's inspection facilities | |||
(Object.getOwnPropertyDescriptor, etc.) | |||
js::dbg2 aims to support debugging interfaces that correlate values in JS programs with DOM trees, CSS rules, and content rendered on the screen. Thus, js::dbg2 proxy objects representing DOM nodes and other interesting host objects should provide extended interfaces to support these sorts of XUL-specific exploration. | |||
= Compilation Hooks And Script Interrogation = | = Compilation Hooks And Script Interrogation = | ||