jsdIStackFrame.pc semantics

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

jsdIStackFrame.pc semantics

John J Barton
The doc for jsdIStackFrame.pc reads:

Current program counter in this stack frame.

I have code like this:
--------
var req = new XMLHttpRequest();

req.onreadystatechange = function() {  // line 3
     if( req.readyState == 4) {
                eval( req.responseText);  // line 5
     }
};
---------

When the eval() executes, within which line should I
expect the program counter for the caller? I expected
line 5, but it comes out on line 6. (Well the numerical
value is 4 since it comes out of pcToLine relative to
the start of the function).

So one model is that the PC is somehow at the end of
the function call:

                eval( req.responseText);  // line 5
---------------------------------------^
so it is just on the next line "barely".

Or there is just another "off-by-one" problem in my code,
not the first I guess ;-).

But I see one case where the PC points to the line
with the eval().

This is all with PCMAP_PRETTYPRINT output, which I guess
really means source-like text decompiled from bytecodes.

Thanks,
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: jsdIStackFrame.pc semantics

Adam L. Peller
John, I may not be parsing your question correctly, but when you're
inside the eval, the top of the stack will tell you you're at line 5 +
whatever line of req.responseText you're at, right? (bug #332176)

You'll probably want PCMAP_SOURCETEXT if you're comparing to the
actual source code.  PCMAP_PRETTYPRINT only makes sense if you compare
against the source the way JSD formats it.

-Adam

> I have code like this:
> --------
> var req = new XMLHttpRequest();
>
> req.onreadystatechange = function() {  // line 3
>      if( req.readyState == 4) {
>                 eval( req.responseText);  // line 5
>      }
> };
> ---------
>
> When the eval() executes, within which line should I
> expect the program counter for the caller? I expected
> line 5, but it comes out on line 6. (Well the numerical
> value is 4 since it comes out of pcToLine relative to
> the start of the function).
>
> So one model is that the PC is somehow at the end of
> the function call:
>
>                 eval( req.responseText);  // line 5
> ---------------------------------------^
> so it is just on the next line "barely".
>
> Or there is just another "off-by-one" problem in my code,
> not the first I guess ;-).
>
> But I see one case where the PC points to the line
> with the eval().
>
> This is all with PCMAP_PRETTYPRINT output, which I guess
> really means source-like text decompiled from bytecodes.
>
> Thanks,
> John.
>
>
> ------------------------------
>
> _______________________________________________
> dev-apps-js-debugger mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-js-debugger
>
>
> End of dev-apps-js-debugger Digest, Vol 11, Issue 6
> ***************************************************
>
_______________________________________________
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: jsdIStackFrame.pc semantics

James Ross
In reply to this post by John J Barton
John J. Barton wrote:
> So one model is that the PC is somehow at the end of
> the function call:
>
>         eval( req.responseText);  // line 5
> ---------------------------------------^
> so it is just on the next line "barely".
>
> Or there is just another "off-by-one" problem in my code,
> not the first I guess ;-).

I believe that when functions are called, the PC still points to the
location of the call, which means it's likely a problem along the lines
Adam mentioned.

--
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: jsdIStackFrame.pc semantics

John J Barton
In reply to this post by John J Barton
Adam, James: sorry, I didn't realize how confusing my example
would be. Let me try to straighten this out.

I was just asking about the "normal" pcToLine at function calls,
not involving eval() or XMLHttpRequest for that matter.

My example used eval() because I have a workaround for bug #332176.
I know the line numbers in eval-ed code overlap the line numbers in
static source.  And that is why I am using PCMAP_PRETTYPRINT because
I don't have the source for the eval-ed code.  But I was just trying
to figure out line numbers for not-eval-ed code.

Just to make it more confusing, my heuristics for non-eval-ed code seem
ok: I wouldn't be asking except that the heuristics don't work for
eval-ed code.  So I wanted to understand the right answer for
non-eval-ed code rather than relying on analysis of the jsd outputs.

So a bit more in direct response to Adam, then I'll repost a new example:

Adam L. Peller wrote:
> John, I may not be parsing your question correctly, but when you're
> inside the eval, the top of the stack will tell you you're at line 5 +
> whatever line of req.responseText you're at, right? (bug #332176)

The top of the stack gives both a line and a PC. The line is mostly
garbage as a far as I see. The PC needs to be converted into a line with
pcToLine. If I use PRETTYPRINT it is relative to, well approximately,
the start of the function. If I use SOURCETEXT, ditto start of the file.
Its that "approximately" bit I was working on, see my next post.

>
> You'll probably want PCMAP_SOURCETEXT if you're comparing to the
> actual source code.  PCMAP_PRETTYPRINT only makes sense if you compare
> against the source the way JSD formats it.

I'm only comparing to jsdIScript.functionSource which I believe is
decompiled from the bytecodes, ie PRETTYPRINT.  Eventually I want to
work with the source of eval-ed code so I don't yet know if I can even
have source.

>
> -Adam
>
>> I have code like this:
>> --------
>> var req = new XMLHttpRequest();
>>
>> req.onreadystatechange = function() {  // line 3
>>      if( req.readyState == 4) {
>>                 eval( req.responseText);  // line 5
>>      }
>> };
>> ---------
>>
>> When the eval() executes, within which line should I
>> expect the program counter for the caller? I expected
>> line 5, but it comes out on line 6. (Well the numerical
>> value is 4 since it comes out of pcToLine relative to
>> the start of the function).
>>
>> So one model is that the PC is somehow at the end of
>> the function call:
>>
>>                 eval( req.responseText);  // line 5
>> ---------------------------------------^
>> so it is just on the next line "barely".
>>
>> Or there is just another "off-by-one" problem in my code,
>> not the first I guess ;-).
>>
>> But I see one case where the PC points to the line
>> with the eval().
>>
>> This is all with PCMAP_PRETTYPRINT output, which I guess
>> really means source-like text decompiled from bytecodes.
>>
>> Thanks,
>> John.
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> dev-apps-js-debugger mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-apps-js-debugger
>>
>>
>> End of dev-apps-js-debugger Digest, Vol 11, Issue 6
>> ***************************************************
>>
_______________________________________________
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: jsdIStackFrame.pc semantics

John J Barton
In reply to this post by John J Barton
Ok now I am starting over.  I realize this may all be too complicated to
sort out.

Here is my new example, a .js file:
---
var dynamic = "var m = 'm';\nvar a;\na = 1 + 2;\na += b;  // line 4";
function first() {
        dump("enter first\n");
        second();  // line 4
        var x1  = 1;
        var y1 = 1;
        var z1 = x1 + y1;
        return z1;
}
function second() {
        dump("enter second\n");
        eval(dynamic);  // line 12
        var x2  = 1;
        var y2 = 1;
        var z2 = x2 + y2;
        return z2;
}
---
I call first() in window.onload.  Here is my stack trace, the format is
Each frame:
<this>.<function>() baseline-extent@pcToLine: line[pcToLine - 2]
where all these values are from frame.script.
Each source line:
(lineToPC)line: lines[line]
where the lines array is from frame.script.functionSource.split('\n');
When I see a line number equal to delta baseline +1 I print >
When I print > and the line contains "eval", I print a line =-=-=
When I see a line number equal to pcToLine I print !

Things to notice:
   1) line[pcToLine - 2] correctly identifies the call except in eval; in
that case its off by one.
   2) line[pcToLine - 1] is too high by one except in eval body ('!'
lines). (lines is zero based so lines[pcToLine - 1] is the line numbered
pcToline.
   3) The difference in base lines ('>') identifies the eval. (BTW also
true for nested eval).
   4) The lineToPc gives zero if the line is before the call point.


---
FireclipseErrorReporter.dumpStack: PRETTYPRINT
Window.second() 12-4@4:     a = 3;
(0)1:    var m = "m";
(3)2:    var a;
(20)3:    a = 3;
(30)!:    a += b;
(30)5:
Window.second() 10-7@4:         eval(dynamic);
(0)1:    function second() {
(0)2:        dump("enter second\n");
(0)>:        eval(dynamic);
=-=-= eval =-=-=
(11)!:        var x2 = 1;
(22)5:        var y2 = 1;
(27)6:        var z2 = x2 + y2;
(32)7:        return z2;
(43)8:    }
Window.first() 2-7@4:         second();
(0)1:    function first() {
(0)2:        dump("enter first\n");
(0)3:        second();
(11)!:        var x1 = 1;
(19)5:        var y1 = 1;
(24)6:        var z1 = x1 + y1;
(29)7:        return z1;
(40)8:    }
---
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger