Debugger: Difference between revisions

127 bytes added ,  4 March 2011
m
→‎Debug.Frame: more formatting and clarifications.
m (→‎Debug.Frame: formatting; clarifications.)
m (→‎Debug.Frame: more formatting and clarifications.)
Line 121: Line 121:
<li><code>"global"</code>: a frame running global code (JavaScript that is neither of the above)
<li><code>"global"</code>: a frame running global code (JavaScript that is neither of the above)
<li><code>"host"</code>: a frame for a call to a host function (I'm not sure if we can obtain these)
<li><code>"host"</code>: a frame for a call to a host function (I'm not sure if we can obtain these)
<li><code>"debugger"</code>: a frame for a call to user code invoked by the debugger
<li><code>"debugger"</code>: a frame for a call to user code invoked by the debugger (see the <code>eval</code> method below)
<li><code>"dummy"</code>: a frame pushed for stupid people (rather&mdash;I don't know what this is)
<li><code>"dummy"</code>: a frame pushed for stupid people (rather&mdash;I don't know what this is)
</ul>
</ul>
(Note that a <code>"debugger"</code> frame represents the debugger continuation expecting the expression's value; the expression itself has its own <code>"eval"</code> frame.)


<dt>older
<dt>older
<dd>The frame in which control will resume when this frame completes.
<dd>The next-older frame, in which control will resume when this frame completes.


<dt>depth
<dt>depth
<dd>The depth of this frame, counting the oldest frame as frame zero.
<dd>The depth of this frame, counting from oldest to youngest; the oldest frame has a depth of zero.


<dt>callee
<dt>callee
Line 137: Line 135:


<dt>generator
<dt>generator
<dd>True if this frame is a generator frame; false otherwise. Present only on frames whose type is <code>"call"</code>.
<dd>True if this frame is a generator frame, false otherwise. Present only on frames whose type is <code>"call"</code>.


<dt>constructing
<dt>constructing
<dd>True if this frame is for a function called as a constructor. Present on <code>"call"</code> and <code>"host"</code> frames.
<dd>True if this frame is for a function called as a constructor, false otherwise. Present on <code>"call"</code> and <code>"host"</code> frames.


<dt>script
<dt>script
Line 149: Line 147:


<dt>environment
<dt>environment
<dd>The lexical environment within which evaluation is taking place (a debuggee value). Present on <code>"call"</code>, <code>"eval"</code>, and <code>"global"</code> frames.
<dd>The lexical environment within which evaluation is taking place (a <code>Debug.Object</code> instance). Present on <code>"call"</code>, <code>"eval"</code>, and <code>"global"</code> frames.


<dt>this
<dt>this
<dd>The value of <code>this</code> for the current frame&mdash (a debuggee value). Present on <code>"call"</code>, <code>"eval"</code>, and <code>"host"</code> frames.
<dd>The value of <code>this</code> for the current frame&mdash;(a debuggee value). Present on <code>"call"</code>, <code>"eval"</code>, and <code>"host"</code> frames.


<dt>arguments
<dt>arguments
Line 164: Line 162:
<dd>Begin evaluating <i>code</i> in the scope of this frame. <i>Code</i> is a string. This pushes a <code>"debugger"</code> frame on the debuggee's stack, evaluates <i>code</i> with all extant hook functions active, and returns a value of the sort passed to an <code>enterFrame</code> completion function describing how the code completed.
<dd>Begin evaluating <i>code</i> in the scope of this frame. <i>Code</i> is a string. This pushes a <code>"debugger"</code> frame on the debuggee's stack, evaluates <i>code</i> with all extant hook functions active, and returns a value of the sort passed to an <code>enterFrame</code> completion function describing how the code completed.


Note that, although this method mixes the debugger's own stack frames with the debuggee's, walking the stack only shows the debuggee's frames; the continuation of the debugger's call to this method, up to the debugging hook function call, is represented by a single <code>"debugger"</code> frame.
Note that, although this method mixes the debugger's own stack frames with the debuggee's, walking the stack only shows the debuggee's frames; the continuation of the debugger's call to this method, up to the debugging hook function call, is represented by a single <code>"debugger"</code> frame. The next younger frame is an <code>"eval"</code> frame running <i>code</i> itself.


<dt>finish(<i>result</i>) <i>(future plan)</i>
<dt>finish(<i>result</i>) <i>(future plan)</i>
<dd>Pop this frame (and any younger frames) from the stack as if this frame had completed. <i>Result</i> is a value of the sort that the <code>interrupt</code> hook might return, indicating how execution should be prepared to continue. Note that this does <emph>not</emph> resume the debuggee's execution; it merely adjusts the debuggee's state to what it would be if this frame's execution had completed. You must return <code>true</code> from the hook function to resume execution in that state.
<dd>Pop this frame (and any younger frames) from the stack as if this frame had completed. <i>Result</i> is a value of the sort that the <code>interrupt</code> hook might return, indicating how execution should be prepared to continue.


This cannot remove any <code>"host"</code> frames (calls through C++) from the stack. (With some clever hacking we might be able to make this work, but it would be ugly.)
Note that this does <i>not</i> resume the debuggee's execution; it merely adjusts the debuggee's state to what it would be if this frame's execution had completed. You must return <code>true</code> from the hook function to resume execution in that state.
 
This cannot remove any <code>"host"</code> frames (calls through C++) from the stack. (We might be able to make this work eventually, but it will take some cleverness.)


<dt>restart(<i>function</i>, <i>this</i>, <i>arguments</i>) <i>(future plan)</i>
<dt>restart(<i>function</i>, <i>this</i>, <i>arguments</i>) <i>(future plan)</i>
<dd>Pop any younger frames from the stack, and then turn this frame into a frame about to begin executing <i>function</i>, with the given <i>this</i> value and <i>arguments</i>. <i>This</i> should be a debuggee value, or <code>{ asConstructor: true }</code> to invoke <i>function</i> as a constructor. <i>Arguments</i> should be an array of debuggee values. This frame must be a <code>"call"</code> frame. Note that this does <emph>not</emph> resume the debuggee's execution; it merely adjusts the debuggee's state to what it would be if this frame were about to make this call. You must return <code>true</code> from the hook function to resume execution in that state.
<dd>Pop any younger frames from the stack, and then turn this frame into a frame about to begin executing <i>function</i>, with the given <i>this</i> value and <i>arguments</i>. <i>This</i> should be a debuggee value, or <code>{ asConstructor: true }</code> to invoke <i>function</i> as a constructor, in which case SpiderMonkey provides an appropriate <code>this</code> value itself. <i>Arguments</i> should be an array of debuggee values. This frame must be a <code>"call"</code> frame.
 
Note that this does <i>not</i> resume the debuggee's execution; it merely adjusts the debuggee's state to what it would be if this frame were about to make this call. You must return <code>true</code> from the hook function to resume execution in that state.


Like <code>finish</code>, this cannot remove <code>"host"</code> frames from the stack.
Like <code>finish</code>, this cannot remove <code>"host"</code> frames from the stack.
Line 183: Line 185:
A generator-iterator object refers to a stack frame with no fixed continuation frame. While the generator's code is running, its continuation is whatever frame called its <code>next</code> method; while the generator is suspended, it has no particular continuation frame; and when it resumes again, the continuation frame for that resumption could be different from that of the previous resumption.
A generator-iterator object refers to a stack frame with no fixed continuation frame. While the generator's code is running, its continuation is whatever frame called its <code>next</code> method; while the generator is suspended, it has no particular continuation frame; and when it resumes again, the continuation frame for that resumption could be different from that of the previous resumption.


When you use the <code>Debug</code> object to inspect a program that is running a generator frame, that frame appears on the stack like any other call frame, except that its <code>generator</code> property is <code>true</code>. Such a frame will disappear from the stack when it is suspended, and reappear (possibly with a different <code>older</code> frame) each time it is resumed.
When you use the <code>Debug</code> object to inspect a program that is running a generator frame, that frame appears on the stack like any other call frame, except that its <code>generator</code> property is <code>true</code>. Such a frame will disappear from the stack when it is suspended, and reappear (possibly with a different <code>older</code> frame and <code>depth</code> value) each time it is resumed.


==Debug.Script==
==Debug.Script==
Confirmed users
497

edits