Confirmed users
496
edits
Platform/JSDebugv2: Difference between revisions
Okay, first cut. I'm going to bed.
(Okay, first cut. I'm going to bed.) |
|||
| Line 52: | Line 52: | ||
In this area, js::dbg2's behavior will not differ much from jsd's, except | 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 | |||
bytecode offsets. | 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.) | |||
= High-level Source Positions = | = High-level Source Positions = | ||
| Line 86: | Line 97: | ||
= Remote Debugging = | = Remote Debugging = | ||
js::dbg2 | js::dbg2 will provide facilities for connecting to a remote XUL process, | ||
either on the same machine or via a network or hardware connection, and | |||
enumerating the spheres present in that process, providing human-readable | |||
descriptions. If the js::dbg2 client expresses an interest in events | |||
occurring in such spheres, a remote debugging session is established. | |||
This communication will be implemented using something resembling V8's [http://code.google.com/p/v8/wiki/DebuggerProtocol Debugger Protocol] and Chrome's [http://code.google.com/p/chromedevtools/wiki/ChromeDevToolsProtocol ChromeDevTools Protocol]. | |||
Remote debugging support will make a number of things possible: | |||
* The debugger UI can move into its own process (say, as a XULrunner application), providing better debugger/debuggee segregation. | |||
* A debugger running in a separate process will be able to provide better chrome debugging, as the debugger won't be trying to operate on its own chrome. | |||
( | * 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). | ||
= Compilation Hooks And Script Interrogation = | = Compilation Hooks And Script Interrogation = | ||