1229586 - Function.call and Function.apply screw up stack-searching in value decompiler

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Shu-yu Guo [:shu]]

mrrrgn reported this.

We implement Function.call by shifting CallArg values in-place "left" by 1. That is, suppose we have |f.call(arg1, arg2)|. At the point of calling into Function.call, SP[-1] is arg2, SP[-2] is arg1. js::fun_call then shifts these: SP[-3] is now arg2, SP[-2] == SP[-1] is arg1. Then we call f, and everything works.

The problem is that if f throws and asks the value decompiler to decompile an argument value, it'll report the wrong PC since the value is at a slot lower.

Not sure how to best fix these cases. Perhaps the decompiler has to know if it's trying to decompile a Function.call or a Function.apply frame. I thought we could copy CallArgs inside js::fun_call, but I don't think that's possible since we need it to store rval.

Comment 1

[Shu-yu Guo [:shu]]

(In reply to Shu-yu Guo [:shu] from comment #0)
> mrrrgn reported this.
> 
> We implement Function.call by shifting CallArg values in-place "left" by 1.
> That is, suppose we have |f.call(arg1, arg2)|. At the point of calling into
> Function.call, SP[-1] is arg2, SP[-2] is arg1. js::fun_call then shifts
> these: SP[-3] is now arg2, SP[-2] == SP[-1] is arg1. Then we call f, and
> everything works.

Argh I got the "js::fun_call then shifts ..." line wrong. It should be:

js::fun_call then shifts these: SP[-3] is now arg1, SP[-2] == SP[-1] is arg2.

Comment 2

[Nicolas B. Pierron [:nbp]]

I don't know if this can help, but this is something that we had to work-around during Ion inlined stack frame iterations [1].

[1] https://dxr.mozilla.org/mozilla-central/source/js/src/jit/JitFrames.cpp#2468