Skip to content

V
V8
Switch branch/tag
  1. 08 Aug, 2018 1 commit
  3. 01 Aug, 2018 1 commit
  5. 31 Jul, 2018 1 commit
    • Michael Achenbach's avatar
      Revert "[builtins] Clear RelocInfo for off-heap trampolines" · 332f5e8c
      Michael Achenbach authored 
      This reverts commit d854d351.

Reason for revert: Speculative revert for webkit unit tests:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/25209

Original change's description:
> [builtins] Clear RelocInfo for off-heap trampolines
> 
> For technical reasons, we used to serialize off-heap trampolines with a
> RelocInfo containing a single OFF_HEAP_TARGET entry. This RelocInfo was
> never needed at runtime. It also ended up being somewhat misleading
> because printing an embedded code object would show the OFF_HEAP_TARGET
> entry (belonging to the trampoline) at the first 'real' instruction.
> 
> With this CL, we explicitly serialize an empty byte array as the reloc
> info for each off-heap trampoline, i.e. the snapshot will never contain
> such off-heap target reloc infos.
> 
> Bug: v8:6666, v8:7969
> Change-Id: If6fa85a438d093ed5dcea07ce0de1db49a224d28
> Reviewed-on: https://chromium-review.googlesource.com/1146643
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54786}

TBR=yangguo@chromium.org,jgruber@chromium.org

Change-Id: If5eabd162141149361df90095b89a173fe2cb81e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666, v8:7969
Reviewed-on: https://chromium-review.googlesource.com/1155594Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54801}
      332f5e8c
  7. 30 Jul, 2018 1 commit
    • jgruber's avatar
      [builtins] Clear RelocInfo for off-heap trampolines · d854d351
      jgruber authored 
      For technical reasons, we used to serialize off-heap trampolines with a
RelocInfo containing a single OFF_HEAP_TARGET entry. This RelocInfo was
never needed at runtime. It also ended up being somewhat misleading
because printing an embedded code object would show the OFF_HEAP_TARGET
entry (belonging to the trampoline) at the first 'real' instruction.

With this CL, we explicitly serialize an empty byte array as the reloc
info for each off-heap trampoline, i.e. the snapshot will never contain
such off-heap target reloc infos.

Bug: v8:6666, v8:7969
Change-Id: If6fa85a438d093ed5dcea07ce0de1db49a224d28
Reviewed-on: https://chromium-review.googlesource.com/1146643
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54786}
      d854d351
  9. 24 Jul, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored 
      This is a reland of a462a785

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

Bug: chromium:863799
Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e
  11. 20 Jul, 2018 2 commits
    • Sigurd Schneider's avatar
      Speculatively revert "[turboassembler] Introduce hard-abort mode" · 039c18e1
      Sigurd Schneider authored 
      This reverts commit a462a785.

Reason for revert: Breaks a TurboAssembler test:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:863799
Reviewed-on: https://chromium-review.googlesource.com/1145431
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54597}
      039c18e1
    • Clemens Hammacher's avatar
      [turboassembler] Introduce hard-abort mode · a462a785
      Clemens Hammacher authored 
      For checks and assertions (mostly for debug code, like stack alignment
or zero extension), we had two modes: Emit a call to the {Abort}
runtime function (the default), and emit a debug break (used for
testing, enabled via --trap-on-abort).
In wasm, where we cannot just call a runtime function because code must
be isolate independent, we always used the trap-on-abort behaviour.
This causes problems for our fuzzers, which do not catch SIGTRAP, and
hence do not detect debug code failures.

This CL introduces a third mode ("hard abort"), which calls a C
function via {ExternalReference}. The C function still outputs the
abort reason, but does not print the stack trace. It then aborts via
"OS::Abort", just like the runtime function.
This will allow fuzzers to detect the crash and even find a nice error
message.

Even though this looks like a lot of code churn, it is actually not.
Most added lines are new tests, and other changes are minimal.

R=mstarzinger@chromium.org

Bug: chromium:863799
Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
Reviewed-on: https://chromium-review.googlesource.com/1142163
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54592}
      a462a785
  13. 09 Jul, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Use relative calls/jumps on arm for builtins · 23dbb81d
      Sigurd Schneider authored 
      This CL uses pc-relative jumps and calls (B/BL) for calls from embedded
builtins to embedded builtins. To make this work, the code range size is
limited to 32MB on arm during mksnapshot, which ensures that all builtin
to builtin offsets for jumps/calls fit into the B/BL immediate. At code
generation time, we put a placeholder into the instruction offset which
we resolve to the right code object when the code is copied to the heap.
We use a new relocation mode RELATIVE_CODE_TARGET for these relative jumps.
The relocation mode RELATIVE_CODE_TARGET should never appear after
generating the snapshot.

We modify the target_address/set_target_address methods of RelocInfo
such that they return the absolute target addresses for pc-relative B/BL
instructions. This ensures that the GC can treat RELATIVE_CODE_TARGET in
the same way as code targets. This, however, only matters during
snapshot creation time, and production code never contains
RELATIVE_CODE_TARGET relocations.

Bug: v8:6666
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If7eab83ad588859ca87c654a5ddc3e37caea884c
Reviewed-on: https://chromium-review.googlesource.com/1117181Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54320}
      23dbb81d
  15. 06 Jul, 2018 1 commit
  17. 05 Jul, 2018 1 commit
  19. 03 Jul, 2018 1 commit
  21. 26 Jun, 2018 1 commit
  23. 22 Jun, 2018 2 commits
  25. 21 Jun, 2018 1 commit
  27. 20 Jun, 2018 4 commits
  29. 19 Jun, 2018 1 commit
  31. 18 Jun, 2018 1 commit
  33. 16 Jun, 2018 1 commit
  35. 14 Jun, 2018 1 commit
  37. 13 Jun, 2018 1 commit
  39. 08 Jun, 2018 1 commit
  41. 07 Jun, 2018 1 commit
  43. 04 Jun, 2018 3 commits
  45. 01 Jun, 2018 1 commit
  47. 30 May, 2018 1 commit
  49. 28 May, 2018 1 commit
  51. 25 May, 2018 1 commit
    • jgruber's avatar
      [builtins,x64] pc-relative builtin-to-builtin calls · e5630ea9
      jgruber authored 
      This addresses one of the major remaining slowdowns with embedded
builtins on x64.

When generating code for a call to a builtin callee from a builtin
caller, we'd look up the Code target object from the builtins constant
list, calculate the location of the first instruction, and jump to it.
Note that for embedded builtin callees, the Code object is itself only
a trampoline to the off-heap code and thus an additional indirection.
An example of the call sequence in pseudo-asm:

// Load from the constants list.
mov reg, [kRootPointer, kBuiltinsConstantListOffset]
mov reg, [reg, offset_of_the_code_constant]
// Calculate first instruction and call it.
add reg, Code::kHeaderOffset
call reg
// The trampoline forwards to the off-heap area.
mov kOffHeapTrampolineRegister, <off-heap instruction_start>
jmp kOffHeapTrampolineRegister

This CL changes calls to embedded builtin targets to use pc-relative
addressing. This reduces the above instruction sequence to:

call <pc-relative offset to target instruction_start>

Embedded-to-embedded calls jump directly to the embedded instruction
stream, bypassing the trampoline. Heap-to-embedded calls (and all
calls to heap-builtins) use pc-relative addressing targeting the
on-heap Code object.

Other relevant platforms (arm,arm64,mips,mips64) do not use pc-relative
calls. For these, we'll need a different solution, e.g. a table of
embedded builtin addresses reachable from the root pointer, similar to
the external reference table.

Bug: v8:6666
Change-Id: Ic0317d454e2da37d74eaecebcdfcbc0d5f5041ad
Reviewed-on: https://chromium-review.googlesource.com/1068732
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53349}
      e5630ea9
  53. 15 May, 2018 1 commit
  55. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored 
      Stubs and builtins are very similar. The main differences are that
stubs can be parameterized and may be generated at runtime, whereas
builtins are generated at mksnapshot-time and shipped with the snapshot
(or embedded into the binary).

My main motivation for these conversions is that we can generate
faster calls and jumps to (embedded) builtins callees from (embedded)
builtin callers. Instead of going through the builtins constants table
indirection, we can simply do a pc-relative call/jump.

This also unlocks other refactorings, e.g. removal of
CallRuntimeDelayed.

TBR=mlippautz@chromium.org

Bug: v8:6666
Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  57. 04 May, 2018 1 commit
  59. 30 Apr, 2018 1 commit
  61. 18 Apr, 2018 1 commit
    • Stephan Herhut's avatar
      Reland "Introduce CodeReference" · 9a200cd2
      Stephan Herhut authored 
      This is a reland of 4d7ad46d

Original change's description:
> Introduce CodeReference
>
> Add a struct CodeReference that can be stack allocated to pass a
> reference to either an on-heap code object or off-heap WasmCode object
> in a gc safe manner. The struct also provides a common interface such
> that code can be written independently of the kind of code object it
> references.
>
> Change-Id: I5a6f74462e6e141d167c7fd9bac8c21941fd83b1
> Reviewed-on: https://chromium-review.googlesource.com/977905
> Commit-Queue: Stephan Herhut <herhut@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52580}

Change-Id: I40861474fe4a3efd72e6c59e2e7b847ab6772735
Reviewed-on: https://chromium-review.googlesource.com/1013939
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52665}
      9a200cd2
  63. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored 
      The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  65. 12 Apr, 2018 1 commit