jsdIScript.functionName semantics

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

jsdIScript.functionName semantics

John J Barton
The API for jsdIScript includes:

---
readonly char* functionName

Function name for this script. "anonymous" for unnamed functions (or a
function actually named anonymous), empty for top level scripts. This
data is copied from the underlying structure when the jsdIScript
instance is created and is therefore available even after the script is
invalidated.

(http://www.xulplanet.com/references/xpcomref/ifaces/jsdIScript.htm)
---

Experimentally (in Javascript) this value is false (null I guess) for
the script objects in stack frames created by eval().  I'm not sure what
"empty" means, but perhaps its means "in Javascript the value will test
false".  The eval() case is not mentioned in the doc. So would the be
correct to say:

  empty for top level scripts and eval-created scripts.

And does that exhaust the possible causes of functionName == null?

In other words,  is "functionName == null plus a stack frame above the
one containing this script" a test for an eval() frame?
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIScript.functionName semantics

James Ross
John J. Barton wrote:
> In other words,  is "functionName == null plus a stack frame above the
> one containing this script" a test for an eval() frame?

Not according to what I can see/know.

The stack frame and script objects both have functionNames. The stack
frame has no functionName (you get null) for top-level execution. The
script (stackFrame.script) has an empty ("") functionName for eval
frames. That's about all I know.

For example, the following code gives:
   var f = function () {
     eval("var a = 1;\ndebugger;\nvar b = 2 * a;");
   };
   f();

    Stack Frame         Script              Venkman Display
    ------------------------------------------------------------
1. "anonymous"         ""                  [EvalScript]
2. "anonymous"         "anonymous"         anonymous
3. null                ""                  __top_level__

If I give the function a name, "_foo", the stack is:

    Stack Frame         Script              Venkman Display
    ------------------------------------------------------------
1. "_foo"              ""                  [EvalScript]
2. "_foo"              "_foo"              _foo
3. null                ""                  __top_level__

And for fun, the script:
   eval("var a = 1;\ndebugger;\nvar b = 2 * a;");

    Stack Frame         Script              Venkman Display
    ------------------------------------------------------------
1. null                ""                  [EvalScript]
2. null                ""                  __top_level__

Venkman identifies __top_level__ scripts by their name (i.e. empty), but
uses some logic about sealed scripts I don't follow to pick out the eval
scripts.

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIScript.functionName semantics

John J Barton
James Ross wrote:
> John J. Barton wrote:
>> In other words,  is "functionName == null plus a stack frame above the
>> one containing this script" a test for an eval() frame?

Oops...my C++/Java background showing... I should say:

Is "functionName == false plus a stack frame above a test for eval()?"
So both null and "" count.
Now let me try your examples...

>
> Not according to what I can see/know.
>
> The stack frame and script objects both have functionNames. The stack
> frame has no functionName (you get null) for top-level execution. The
> script (stackFrame.script) has an empty ("") functionName for eval
> frames. That's about all I know.
>
> For example, the following code gives:
>   var f = function () {
>     eval("var a = 1;\ndebugger;\nvar b = 2 * a;");
>   };
>   f();
>
>    Stack Frame         Script              Venkman Display
>    ------------------------------------------------------------
> 1. "anonymous"         ""                  [EvalScript]
> 2. "anonymous"         "anonymous"         anonymous
> 3. null                ""                  __top_level__

The center column is false, true, false. #3 is false but top level. So
false and not-top works to identify EvalScript using the Script col.

>
> If I give the function a name, "_foo", the stack is:
>
>    Stack Frame         Script              Venkman Display
>    ------------------------------------------------------------
> 1. "_foo"              ""                  [EvalScript]
> 2. "_foo"              "_foo"              _foo
> 3. null                ""                  __top_level__

Ditto.


> And for fun, the script:
>   eval("var a = 1;\ndebugger;\nvar b = 2 * a;");
>
>    Stack Frame         Script              Venkman Display
>    ------------------------------------------------------------
> 1. null                ""                  [EvalScript]
> 2. null                ""                  __top_level__

Ditto.
Hey, three examples, must be so ;-)

>
> Venkman identifies __top_level__ scripts by their name (i.e. empty), but
> uses some logic about sealed scripts I don't follow to pick out the eval
> scripts.

Oh that's a great hint.  I could not figure out what Venkman was up to.
But now I have a guess.  It analyzes all scripts on creation.  It uses
the first empty name to mark __top_level__.  Because it knows that no
function at compile time will be empty name except top level and that
script comes last in the compile sequence. At the same time it marks the
page ("instance") as "sealed", ie "I saw the top level".  After that all
scripts that are created must be EvalScript. (Granted there is some
funky code about _lastScriptWrapper but it seems consistent with this
model).

The key assertion is "no function at compile time will be empty name
except top level". Or "every empty name other than top level must be
from runtime, ie eval".

You buying that ;-)

JOhn.
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIScript.functionName semantics

James Ross
John J. Barton wrote:

> James Ross wrote:
>> Venkman identifies __top_level__ scripts by their name (i.e. empty),
>> but uses some logic about sealed scripts I don't follow to pick out
>> the eval scripts.
>
> Oh that's a great hint.  I could not figure out what Venkman was up to.
> But now I have a guess.  It analyzes all scripts on creation.  It uses
> the first empty name to mark __top_level__.  Because it knows that no
> function at compile time will be empty name except top level and that
> script comes last in the compile sequence. At the same time it marks the
> page ("instance") as "sealed", ie "I saw the top level".  After that all
> scripts that are created must be EvalScript. (Granted there is some
> funky code about _lastScriptWrapper but it seems consistent with this
> model).
>
> The key assertion is "no function at compile time will be empty name
> except top level". Or "every empty name other than top level must be
> from runtime, ie eval".
>
> You buying that ;-)

I'll buy that alright; I never did log all the script wrapper and
instances and sealing stuff, but counting all non-function scripts after
the first as evals would fit.

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: jsdIScript.functionName semantics

John J Barton
Here's another way to think about the "empty-function-name" functions.

Consider the code:
---
var a = 1;        // 1: not in named function body
a += 1;           // 2: ditto
function foo() {
   return 2;       // 4: Function "foo"
}
--

If this code is in a web page, then lines 1 and 2 are part of the
__top_level__ function with an empty name.

If this code is eval()ed, then lines 1 and 2 are part of ... ah, er,
the eval-level function with an empty name.

In both cases the bytecodes for this out-of-body code can only be
executed once, which I suppose is why the engine does not keep it
around. Also in both cases the function "foo" is a JavaScript function
with a name that can be called.

The top-level function runs at the top of the stack while the eval-level
function with an empty name runs in a stack frame with at least one
caller. Of course a significant difference between these cases is the
subject of bug #332176: the debugger does not have the source for the
eval-level or for foo() in the eval case.

John.

James Ross wrote:

> John J. Barton wrote:
>> James Ross wrote:
>>> Venkman identifies __top_level__ scripts by their name (i.e. empty),
>>> but uses some logic about sealed scripts I don't follow to pick out
>>> the eval scripts.
>>
>> Oh that's a great hint.  I could not figure out what Venkman was up
>> to. But now I have a guess.  It analyzes all scripts on creation.  It
>> uses the first empty name to mark __top_level__.  Because it knows
>> that no function at compile time will be empty name except top level
>> and that script comes last in the compile sequence. At the same time
>> it marks the page ("instance") as "sealed", ie "I saw the top level".  
>> After that all scripts that are created must be EvalScript. (Granted
>> there is some funky code about _lastScriptWrapper but it seems
>> consistent with this model).
>>
>> The key assertion is "no function at compile time will be empty name
>> except top level". Or "every empty name other than top level must be
>> from runtime, ie eval".
>>
>> You buying that ;-)
>
> I'll buy that alright; I never did log all the script wrapper and
> instances and sealing stuff, but counting all non-function scripts after
> the first as evals would fit.
>
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger