Skip to content

V
V8
Switch branch/tag
  1. 04 Dec, 2018 4 commits
  3. 20 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      Print readable register names · de2681c1
      Clemens Hammacher authored 
      This adds a {PrintRegister} method which prints the given register in a
readable way (e.g. "eax", ... on ia32).
This is currently only used in Liftoff. The {RegisterConfiguration}
class has the same functionality, and I plan to make
{RegisterConfiguration} also use the new {RegisterName} functions in a
follow-up CL.

R=mstarzinger@chromium.org

Bug: v8:8238, v8:8423, v8:6600
Change-Id: If03901f1d8c5b043e0097e63920ab711bd7e2d17
Reviewed-on: https://chromium-review.googlesource.com/c/1340041Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57646}
      de2681c1
  5. 19 Nov, 2018 1 commit
  7. 26 Oct, 2018 1 commit
  9. 19 Oct, 2018 1 commit
  11. 01 Oct, 2018 1 commit
  13. 21 Sep, 2018 1 commit
  15. 20 Sep, 2018 1 commit
  17. 19 Sep, 2018 1 commit
  19. 15 Sep, 2018 1 commit
  21. 11 Sep, 2018 1 commit
  23. 17 Aug, 2018 1 commit
  25. 08 Aug, 2018 1 commit
  27. 01 Aug, 2018 1 commit
  29. 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
  31. 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
  33. 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
  35. 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
  37. 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
  39. 06 Jul, 2018 1 commit
  41. 05 Jul, 2018 1 commit
  43. 03 Jul, 2018 1 commit
  45. 26 Jun, 2018 1 commit
  47. 22 Jun, 2018 2 commits
  49. 21 Jun, 2018 1 commit
  51. 20 Jun, 2018 4 commits
  53. 19 Jun, 2018 1 commit
  55. 18 Jun, 2018 1 commit
  57. 16 Jun, 2018 1 commit
  59. 14 Jun, 2018 1 commit
  61. 13 Jun, 2018 1 commit
  63. 08 Jun, 2018 1 commit