Fix LookupCode for the DatePrototype_GetField builtin

Fix LookupCode for the DatePrototype_GetField builtin

This was exposed on win64 and manifested as a negative offset during
stack frame collection, i.e. pc < Code::instruction_start() for a
BUILTIN frame.

This happened because StackFrame::LookupCode returns the wrong code
object when call is the last instruction in a code object:
* pc is actually the return address for all but the topmost frame.
* pc points at the next instruction after the call.
* This is beyond the current code object if call is the last
  instruction.
* Lookup itself is naive in that it just returns the first code object
  for which (next_code_obj_addr > pc). It does not check that pc is
  actually within [instruction_start, instruction_end[.
* In this specific case, the pc (== return address) actually pointed
  at the beginning of the header of the next code object.
* We finally calculated offset as (code->instruction_start() - pc),
  but with the wrong code object.

This should be followed up by a proper fix at some point. For instance,
this could be setting pc to (return address - 1) for all but the topmost
frame.

BUG=v8:5311
Committed: https://crrev.com/4f781d72491ce092bd7cb34bc677eeed3e63eda3
Cr-Commit-Position: refs/heads/master@{#38996}

[jgruber, 2016-08-26 13:57:04]

The CQ bit was checked by jgruber@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-26 13:57:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jgruber, 2016-08-26 14:10:11]

jgruber@chromium.org changed reviewers:
+ mstarzinger@chromium.org

[commit-bot: I haz the power, 2016-08-26 14:17:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-26 14:18:00]

Dry run: This issue passed the CQ dry run.

[jgruber, 2016-08-30 07:55:15]

jgruber@chromium.org changed reviewers:
+ bmeurer@chromium.org

[Benedikt Meurer, 2016-08-30 08:02:05]

lgtm

[jgruber, 2016-08-30 08:04:01]

The CQ bit was checked by jgruber@chromium.org

[commit-bot: I haz the power, 2016-08-30 08:04:10]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 08:27:56]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-08-30 08:28:23]

Description was changed from

==========
Fix LookupCode for the DatePrototype_GetField builtin

This was exposed on win64 and manifested as a negative offset during
stack frame collection, i.e. pc < Code::instruction_start() for a
BUILTIN frame.

This happened because StackFrame::LookupCode returns the wrong code
object when call is the last instruction in a code object:
* pc is actually the return address for all but the topmost frame.
* pc points at the next instruction after the call.
* This is beyond the current code object if call is the last
  instruction.
* Lookup itself is naive in that it just returns the first code object
  for which (next_code_obj_addr > pc). It does not check that pc is
  actually within [instruction_start, instruction_end[.
* In this specific case, the pc (== return address) actually pointed
  at the beginning of the header of the next code object.
* We finally calculated offset as (code->instruction_start() - pc),
  but with the wrong code object.

This should be followed up by a proper fix at some point. For instance,
this could be setting pc to (return address - 1) for all but the topmost
frame.

BUG=v8:5311
==========

to

==========
Fix LookupCode for the DatePrototype_GetField builtin

This was exposed on win64 and manifested as a negative offset during
stack frame collection, i.e. pc < Code::instruction_start() for a
BUILTIN frame.

This happened because StackFrame::LookupCode returns the wrong code
object when call is the last instruction in a code object:
* pc is actually the return address for all but the topmost frame.
* pc points at the next instruction after the call.
* This is beyond the current code object if call is the last
  instruction.
* Lookup itself is naive in that it just returns the first code object
  for which (next_code_obj_addr > pc). It does not check that pc is
  actually within [instruction_start, instruction_end[.
* In this specific case, the pc (== return address) actually pointed
  at the beginning of the header of the next code object.
* We finally calculated offset as (code->instruction_start() - pc),
  but with the wrong code object.

This should be followed up by a proper fix at some point. For instance,
this could be setting pc to (return address - 1) for all but the topmost
frame.

BUG=v8:5311

Committed: https://crrev.com/4f781d72491ce092bd7cb34bc677eeed3e63eda3
Cr-Commit-Position: refs/heads/master@{#38996}
==========

[commit-bot: I haz the power, 2016-08-30 08:28:25]

Patchset 1 (id:??) landed as
https://crrev.com/4f781d72491ce092bd7cb34bc677eeed3e63eda3
Cr-Commit-Position: refs/heads/master@{#38996}