Skip to content

V
V8
Switch branch/tag
  1. 22 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Rewrite Function.prototype.toString in C++. · 4acca53e
      bmeurer authored 
      There's actually no point trying to do Function.prototype.toString in
JavaScript, as it always calls into C++ at least once, so it only
complicates things (esp. once we start optimizing bound functions).

Drive-by-fix: Rename FunctionApply and FunctionCall builtins to also
reflect the fact that these are builtins in the Function.prototype and
not on Function itself.

TBR=hpayer@chromium.org
R=yangguo@chromium.org
BUG=chromium:535408
LOG=n

Review URL: https://codereview.chromium.org/1540953004

Cr-Commit-Position: refs/heads/master@{#32996}
      4acca53e
  3. 18 Dec, 2015 1 commit
  5. 17 Dec, 2015 2 commits
  7. 16 Dec, 2015 3 commits
    • yangguo's avatar
      [debugger] simplify step over recursive function call. · 2bb6e197
      yangguo authored 
      The problem is this: when stepping over a recursive function call,
the recursive function is flooded with one-shot break points so that
we break after the call, but since the callee is the same function,
the callee is also flooded, resulting a break in the callee. That
however would have been a "step in" instead of "step over".

The original solution was to recognize this by comparing FP. If we
end up in Debug::Break, we still have to check the current FP against
the remembered FP to see whether we are on the same stack height.
If we are deeper, then it's not a "step over", and we do not trigger
a debug break event. In that case, we queue up the step-over, and
temporarily step out until we hit the desired stack height. Note that
in order to step out, we flood the caller, which in our example is
the same function as the callee. So we break at every flooded break
location, and comparing with FP to make sure we stepped out prevents
us from triggering debug break events.

The new solution simply ignores breaks when the FP compare fails.
We simply carry on until we hit a break where the FP compare succeeds.
There is no need to do a step out. The number of calls to Debug::Break
that do not trigger a debug break event due to failing FP compare is
the same. But the code is a lot easier to read.

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/1527253002

Cr-Commit-Position: refs/heads/master@{#32897}
      2bb6e197
    • yangguo's avatar
      [debugger] remove step count parameter from prepare step. · 8bee91a5
      yangguo authored 
      And tons of changes to debugger tests.

R=bmeurer@chromium.org
BUG=chromium:569835
LOG=N

Review URL: https://codereview.chromium.org/1525173003

Cr-Commit-Position: refs/heads/master@{#32885}
      8bee91a5
    • yangguo's avatar
      [debugger] remove some dead code. · b68f7e4c
      yangguo authored 
      credits to gcov.

R=cbruni@chromium.org

Review URL: https://codereview.chromium.org/1522273003

Cr-Commit-Position: refs/heads/master@{#32877}
      b68f7e4c
  9. 15 Dec, 2015 4 commits
  11. 14 Dec, 2015 3 commits
    • machenbach's avatar
      Revert of [debugger] debug-evaluate should not not modify local values.... · a2f2e913
      machenbach authored 
      Revert of [debugger] debug-evaluate should not not modify local values. (patchset #2 id:20001 of https://codereview.chromium.org/1513183003/ )

Reason for revert:
[Sheriff] Layout test changes.

Original issue's description:
> [debugger] debug-evaluate should not not modify local values.
>
> Debug evaluate no longer writes back changes to the replicated
> context chain to the original after execution. Changes to the
> global object or script contexts still stick. Calling functions
> that bind to the original context chain also have their expected
> side effects.
>
> As far as I can tell, DevTools is not interested in modifying
> local variable values. Modifying global variable values still
> works as expected. However, I have not yet removed the old
> implementation, but merely keep it behind a flag.
>
> R=mstarzinger@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
> Cr-Commit-Position: refs/heads/master@{#32841}

TBR=mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1526553003

Cr-Commit-Position: refs/heads/master@{#32845}
      a2f2e913
    • yangguo's avatar
      [debugger] debug-evaluate should not not modify local values. · 92caa9b8
      yangguo authored 
      Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.

As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.

R=mstarzinger@chromium.org, rossberg@chromium.org

Review URL: https://codereview.chromium.org/1513183003

Cr-Commit-Position: refs/heads/master@{#32841}
      92caa9b8
    • yangguo's avatar
      [debugger] fix debug-evaluate wrt shadowed context var. · 089edbfa
      yangguo authored 
      Debug-evaluate used to resolve stack variables that shadow
context variables incorrectly, since the stack variable is
not visible in the context chain.

To fix this, we limit local variables accessible by debug-
evaluate to the ones directly referenced inside the function.
What is not referenced by the function itself, is considered
optimized out and not accessible by debug-evaluate.

To achieve this, we duplicate the entire context chain up to
the native context, and write back changes after debug-
evaluate. Changes to the original context chain will however
be overwritten. This already happens for catch and block
scopes though.

Also fix a crash caused by declaring variables inside debug-
evaluate.

R=mstarzinger@chromium.org
BUG=v8:4593
LOG=N

Review URL: https://codereview.chromium.org/1500933002

Cr-Commit-Position: refs/heads/master@{#32828}
      089edbfa
  13. 07 Dec, 2015 2 commits
  15. 04 Dec, 2015 5 commits
  17. 03 Dec, 2015 7 commits
  19. 02 Dec, 2015 4 commits
  21. 01 Dec, 2015 1 commit
  23. 30 Nov, 2015 1 commit
  25. 27 Nov, 2015 2 commits
  27. 26 Nov, 2015 4 commits