Right now, if you step into a function with 'arguments', you first observe the frame where 'arguments' is 'undefined'. On the next step, 'arguments' becomes the expected arguments object. That is because the arguments object is created by the JSOP_ARGUMENTS in the first few ops of script->code. Now, script->main points to after this prologue and, iirc, I fixed getAllOffsets et al to start at script->main (to avoid breaking some debugger shell tests that seemed to be making assumptions about the first offset). This bug is to fix single-stepping to do the same to avoid annoying/confusing the debugger user.
Yeah, I agree that those intermediate states should be hidden from the debugger. None of those opcodes can raise an exception, can they? (Other than OOM, which I think we're agreed needn't be something the debugger can properly observe.)
Should this bug be expanded to address breakpoints at offset zero?
(In reply to Jim Blandy :jimb from comment #1) They can oom and I think it is fine if the frame is observed, in exceptional circumstances. It should certainly not crash (once we fix the boogs). (In reply to Jim Blandy :jimb from comment #2) > Should this bug be expanded to address breakpoints at offset zero? I think I already tweaked the getAllOffsets to not return offsets before script->main. Given that, is there any way the average user would accidentally set a breakpoint at 0? If they do it intentionally, that seems fine.
Seems to me coordinates for breaking and stuff should be line/column (or character, whatever) source coordinates. Then you're not encoding bytecode offsets, even as magic numbers, into the API. Of course that requires we track column info, but we're going to have to do that at some point anyway. :-)
You need to log in before you can comment on or make changes to this bug.