Added mutation of locals to debugger

Added mutation of locals to debugger.

The locals can now be mutated in the debugger. After a debugger evaluation the content of the scope created for the evaluation is written back to where it was originally picked from (context extension, context, stack locals, stack parameters and possibly adaptor frame stack parameters).

Fixed an issue of evaluating arguments through arguments[n] in the debugger in some senarios. If n was larger than the functions formal parameters count and the arguments object was not used by the function arguments[n] used to resolve to undefined, as the precense of an arguments adaptor frame was not taken into account. Now all the passed parameters are added to the arguments object which is sometimes created for the evaluation function. If there is an arguments adaptor frame the arguments are picked from there.

BUG=212
TEST=test\mjsunit\debug-evaluate.js

[Mads Ager (chromium), 2009-06-15 11:48:28]

LGTM

http://codereview.chromium.org/125115/diff/1/4
File src/runtime.cc (right):

http://codereview.chromium.org/125115/diff/1/4#newcode6165
Line 6165: // Write back the to the local scope from a materialized local scope.
the to the -> to the

[Kevin Millikin (Chromium), 2009-06-15 12:15:23]

As we discussed a bit offline, this will not work as-is right now.

The code generator tracks whether stack-allocated locals and parameters are
known at compile-time ("constant") or alias each other, and also whether they
are known to be strings, heap objects, or smis.  This information is used to
make code generation decisions.  None of this information is destroyed by a
call.

That means that we can generate incorrect (and unsafe) code in the event that a
local is changed.

[Søren Thygesen Gjesse, 2009-06-15 12:37:11]

I will hold back this change until we have a safe way of leaving the debugger
with the content of variables/arguments/contexts changed to a type not expected
by the static analysis used by the code generator.

On 2009/06/15 12:15:23, Kevin Millikin wrote:
> As we discussed a bit offline, this will not work as-is right now.
> 
> The code generator tracks whether stack-allocated locals and parameters are
> known at compile-time ("constant") or alias each other, and also whether they
> are known to be strings, heap objects, or smis.  This information is used to
> make code generation decisions.  None of this information is destroyed by a
> call.
> 
> That means that we can generate incorrect (and unsafe) code in the event that
a
> local is changed.

[Søren Thygesen Gjesse, 2009-06-15 14:05:21]

Added two tests which exposes some of the issues of providing wrong results and
throwing unexpected runtime exceptions from the runtime system. No hard crashes
has yet been found with the current level of optimizations.