The break location heavily relies on relocation info. This change
abstracts that away. Currently there is only one implementation for
this interface, for JIT code. Future changes will introduce an
implementation to iterate bytecode arrays.

R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33869}

Generally we only care whether the next object is a hidden prototype.
It's simpler to check whether the current object has a hidden prototype
instead of walking to the next prototype and checking its map.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33816}

This makes the field in question more generic by renaming it from the
previous "depth" to "data". Pure refactoring, no function change.

R=rmcilroy@chromium.org,yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33779}

The CL 33579 (https://codereview.chromium.org/1618343002) use code offsets instead of raw PC where possible.

But the offset maybe come from an optimized frame, not the un-optimized frame that FromCodeOffset and BreakIndexFromCodeOffset function expect.
So The offset from optimized frame can't be used in FromCodeOffset and  BreakIndexFromCodeOffset function.

This CL use the frame summary to find the corresponding code offset in unoptimized code according to Yang's suggestion.

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

Cr-Commit-Position: refs/heads/master@{#33778}

Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )

Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33766}

BUG=v8:4724, v8:1543
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33747}

(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33741}

In the debugger we are interested in getting the context for the
current frame, which is usually a function context. To do that,
we used to call Context::declaration_context, which may also
return a block context. This is wrong and can lead to crashes.
Instead, we now use a newly introduced Context::closure_context,
which skips block contexts. This works fine for the debugger,
since we have other means to find and materialize block contexts.

R=rossberg@chromium.org
BUG=chromium:582051
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33627}

String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:

if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
  /* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);

This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.

No observable change in behavior is intended.

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

Cr-Commit-Position: refs/heads/master@{#33616}

This change adds AbstractCode, which can be either Code or
BytecodeArray, and adds methods to calculate source position based
on that. Also cleans up to use code offsets instead of raw PC
where possible, and consistently uses the offset from instruction
start (as opposed to code object start).

R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33579}

Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33556}

(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33548}

A statement could have several break positions. The entire statement
should be considered muted if break points across all these break
positions evaluate to false.

R=verwaest@chromium.org
BUG=chromium:429167
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33522}

Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )

Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33520}

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33518}

These features are not used by devtools and consequently not
exposed through the devtools protocol. They make the debugger
unnecessarily complex. If we decide that we need this, we should
implement this on a higher layer.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33436}

A break location is considered muted if it has break points, but their
conditions all evaluate to false. Aside from not triggering break
events, debugger statements and exceptions are also ignored.

R=verwaest@chromium.org
BUG=chromium:429167
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#33429}

R=ulan@chromium.org
BUG=chromium:567937
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33298}

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}

Now that we do not support arbitrary step count anymore, we can
make this a lot easier.

R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32966}

And remove confusing comment.

R=bmeurer@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#32935}

Add Ivica B.

NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#32933}

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}

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}

credits to gcov.

R=cbruni@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32877}

The third argument optionally specifies the frame from which to step.
This feature is not used and not well tested.

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

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

Cr-Commit-Position: refs/heads/master@{#32865}

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32861}

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}

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

Cr-Commit-Position: refs/heads/master@{#32857}

We used to flood the handler when preparing for stepping,
even if we may not throw. Instead, we now flood the
handler only when we actually throw.

This also solves an issue with step-next when we throw and
leave the function unexpectedly. In combination with
microtasks, this could cause a crash.

R=mstarzinger@chromium.org
BUG=chromium:568477
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#32856}

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}

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}

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}

  port 1e671030 (r32614)

  original commit message:

BUG=

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

Cr-Commit-Position: refs/heads/master@{#32641}

X87: Reland of [debugger] do not restart frames that reference new.target for liveedit. (patchset #1 id:1 of https://codereview.chromium.org/1493863004/ )

  port 15cb3fde (r32587)

  original commit message:
  Reason for revert:
  Didn't help...

  Original issue's description:
  > Revert of [debugger] do not restart frames that reference new.target for liveedit. (patchset #1 id:1 of https://codereview.chromium.org/1493363002/ )
  >
  > Reason for revert:
  > [Sheriff] Speculative revert for https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3225
  >
  > Original issue's description:
  > > [debugger] do not restart frames that reference new.target for liveedit.
  > >
  > > R=mstarzinger@chromium.org
  > >
  > > Committed: https://crrev.com/6fca870240bdbb07a365189b5eb0c98fa65b3682
  > > Cr-Commit-Position: refs/heads/master@{#32572}
  >
  > TBR=mstarzinger@chromium.org,yangguo@chromium.org
  > NOPRESUBMIT=true
  > NOTREECHECKS=true
  > NOTRY=true
  >
  > Committed: https://crrev.com/1a61dab34b9849f3f70a42ce69317e22758c53a1
  > Cr-Commit-Position: refs/heads/master@{#32582}

BUG=

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

Cr-Commit-Position: refs/heads/master@{#32637}

Port 1e671030

R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#32625}

Having beefed up GetKeys() to support everything, use it for everything now.

This fixes Object.getOwnPropertyNames and Object.getOwnPropertySymbols for
Proxies, and gets rid of a bunch of code duplication.

BUG=v8:1543
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32620}

R=verwaest@chromium.org

Committed: https://crrev.com/8f87ff5d62e996b07ffbde7e735daa603c1d7290
Cr-Commit-Position: refs/heads/master@{#32553}

Committed: https://crrev.com/00559c4584fe3a4c3c1a8d3a5b5af0611b19c40a
Cr-Commit-Position: refs/heads/master@{#32600}

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

Cr-Commit-Position: refs/heads/master@{#32614}

Revert of [debugger] do not predict step in target for liveedit. (patchset #2 id:20001 of https://codereview.chromium.org/1491743005/ )

Reason for revert:
[Sheriff] And it still breaks:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3239

Please run chromium trybots on relands of CLs that broke chromium bots.

Original issue's description:
> [debugger] do not predict step in target for liveedit.
>
> R=verwaest@chromium.org
>
> Committed: https://crrev.com/8f87ff5d62e996b07ffbde7e735daa603c1d7290
> Cr-Commit-Position: refs/heads/master@{#32553}
>
> Committed: https://crrev.com/00559c4584fe3a4c3c1a8d3a5b5af0611b19c40a
> Cr-Commit-Position: refs/heads/master@{#32600}

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

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

Cr-Commit-Position: refs/heads/master@{#32607}

R=verwaest@chromium.org

Committed: https://crrev.com/8f87ff5d62e996b07ffbde7e735daa603c1d7290
Cr-Commit-Position: refs/heads/master@{#32553}

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

Cr-Commit-Position: refs/heads/master@{#32600}

Port 6fca8702

R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#32589}