1. 01 Oct, 2018 1 commit
  2. 21 Sep, 2018 1 commit
  3. 20 Sep, 2018 1 commit
  4. 19 Sep, 2018 1 commit
  5. 15 Sep, 2018 1 commit
  6. 11 Sep, 2018 1 commit
  7. 17 Aug, 2018 1 commit
  8. 08 Aug, 2018 1 commit
  9. 01 Aug, 2018 1 commit
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  16. 05 Jul, 2018 1 commit
  17. 03 Jul, 2018 1 commit
  18. 26 Jun, 2018 1 commit
  19. 22 Jun, 2018 2 commits
  20. 21 Jun, 2018 1 commit
  21. 20 Jun, 2018 4 commits
  22. 19 Jun, 2018 1 commit
  23. 18 Jun, 2018 1 commit
  24. 16 Jun, 2018 1 commit
  25. 14 Jun, 2018 1 commit
  26. 13 Jun, 2018 1 commit
  27. 08 Jun, 2018 1 commit
  28. 07 Jun, 2018 1 commit
  29. 04 Jun, 2018 3 commits
  30. 01 Jun, 2018 1 commit
  31. 30 May, 2018 1 commit
  32. 28 May, 2018 1 commit
  33. 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