1. 04 Sep, 2019 1 commit
  2. 03 Sep, 2019 1 commit
    • Pierre Langlois's avatar
      [arm64] Fix backwards branch ranges. · ffffed90
      Pierre Langlois authored
      The `Instruction::IsValidImmPCOffset()` method was taking an `offset` argument
      in numbers of *instructions* while we were passing it numbers of *bytes*. See
      `Instruction::IsTargetInImmPCOffsetRange()` and
      `MacroAssembler::NeedExtraInstructionsOrRegisterBranch()`.
      
      As a result, we were 4 times too conservative when computing branch ranges going
      backwards, forcing us to generate the following sequence for TBZ more often than
      needed:
      
      ```
        TBNZ <skip>
        B <target>
      skip:
      ```
      
      This happened rarely for loops, but a lot when doing an early return from
      out-of-line calls to write barriers. Since out-of-line code is easily out of
      range of 8K, although the real range of TBZ is 32K.
      
      This fixes it by changing this method to take a byte offset instead of
      instructions, as this is more intuitive and in line with similar methods. For
      instance, `Instruction::ImmPcOffset()` returns an offset in bytes.
      
      The tests are adapted so that they would have caught such a bug:
      
      * TEST(far_branch_backward):
      
        This test used to only check the code worked if the branch was very far away,
        but it didn't test the range was correct. So this test was changed to check
        each branch type separately, and test in-range and out-of-range cases
        separately too.
      
      * TEST(far_branch_veneer_broken_link_chain):
      
        Because of the backwards range bug, this test wasn't actually testing what it
        should. The idea of the test is to make sure the MacroAssembler can still cope
        when the chain of links is broken after a veneer was emitted. But no veneers
        were ever emitted.
      
      Change-Id: Iddb5c683a71147455175f38fa7ae57da0a3e7337
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781058Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63518}
      ffffed90
  3. 24 Jul, 2019 1 commit
  4. 18 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      Reland "[arm64] Refactor constant pool implementation" · e93d244f
      Sigurd Schneider authored
      This is a reland of ac79b539
      
      This CL adds a missing BlockPoolsScope to guard a RequestHeapObject
      call. This fixes a latend bug that the original land flushed out.
      
      Original change's description:
      > [arm64] Refactor constant pool implementation
      >
      > This refactors the constant pool handling for arm64. The immediate goal
      > is to allow 32bit compressed pointers in the pool. The mediate goal is
      > to unify the implementation with the arm constant pool, which will be
      > done in a follow-up CL.
      >
      > Bug: v8:8054
      > Change-Id: I74db4245e5e1025f2e4de4144090fa4ce25883ab
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645316
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62209}
      
      TBR=mstarzinger@chromium.org,jgruber@chromium.org,georgia.kouveli@arm.com
      
      Bug: v8:8054
      Change-Id: I1e3ab13619a48caad33d77ed8bed86782f9d9674
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664054Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62237}
      e93d244f
  5. 17 Jun, 2019 2 commits
  6. 12 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      [arm64,test] Generate code object in assembler tests · 4c0bf17e
      Sigurd Schneider authored
      This is pre-work for a refactoring that changes how heap objects
      are handled in the assembler: Currently, we put the handle location in
      the constant pool, and replace these with the actual heap object when
      we copy the code from the assembler's buffer to the heap.
      
      In the future, we will put a small index in the constant pool, which
      will ultimately enable 32bit constant pool slots for compressed heap
      objects. This small index will be fixed up when we copy the code to
      the heap.
      
      This CL makes the assembler tests copy the code to the heap, which
      ensures that the fix-up phase is actually run.
      
      Change-Id: I80cd69dc57414a3bd0a27f8d558616aadcae05a2
      Bug: v8:7703
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647166
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62112}
      4c0bf17e
  7. 04 Jun, 2019 1 commit
  8. 28 May, 2019 1 commit
  9. 27 May, 2019 1 commit
  10. 24 May, 2019 1 commit
  11. 21 May, 2019 1 commit
  12. 02 May, 2019 1 commit
  13. 30 Apr, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[ptr-compr] New RelocInfo for compressed pointers." · ed319e84
      Mike Stanton authored
      Failure addressed by not exposing the new test to the jitless environment.
      (jgruber@ on TBR).
      
      New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
      compressed pointers in generated code. Enum name EMBEDDED_OBJECT
      changed to FULL_EMBEDDED_OBJECT.
      
      RelocInfo::[set_]target_object() abstract away the difference between
      FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.
      
      Compressed embedded objects can only be created at this time on
      x64 with pointer compression turned on. Arm64 constant pools don't
      support compressed objects at this time.
      
      NOPRESUBMIT=true
      
      Bug: v8:7703
      TBR: jgruber@chromium.org
      Change-Id: Ifff53b041bab09b4b8c3e16085e5df4aa2b99f4f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588461Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61104}
      ed319e84
  14. 29 Apr, 2019 4 commits
  15. 05 Mar, 2019 1 commit
  16. 19 Feb, 2019 1 commit
  17. 05 Feb, 2019 2 commits
  18. 30 Jan, 2019 1 commit
  19. 17 Jan, 2019 3 commits
  20. 29 Nov, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [wasm] Add more unit tests for trap handler · 3d2bc5d0
      Andreas Haas authored
      The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
      
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Patchset 1 is the original CL.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
      Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57947}
      3d2bc5d0
  21. 27 Nov, 2018 2 commits
    • Clemens Hammacher's avatar
      Revert "[wasm] Add more unit tests for trap handler" · 2fd07376
      Clemens Hammacher authored
      This reverts commit 4644b32e.
      
      Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
      
      Original change's description:
      > [wasm] Add more unit tests for trap handler
      > 
      > The unittests test if the trap handler only handles those traps it
      > is supposed to handle:
      > * Only handle traps when the thread-in-wasm flag is set.
      > * Only handle traps of the right type, i.e. memory access violations.
      > * Only handle traps at recorded instructions.
      > 
      > The tests also test the consistency of the thread-in-wasm flag. I made
      > one change in the trap handler where that consistency could be
      > violated.
      > 
      > All tests are executed with the default trap handler provided by V8,
      > and with the trap handler callback installed in a test signal/exception
      > handler.
      > 
      > Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57858}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
      
      Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/1351021Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57861}
      2fd07376
    • Andreas Haas's avatar
      [wasm] Add more unit tests for trap handler · 4644b32e
      Andreas Haas authored
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57858}
      4644b32e
  22. 24 Oct, 2018 1 commit
  23. 23 Oct, 2018 2 commits
  24. 18 Oct, 2018 1 commit
  25. 06 Sep, 2018 1 commit
  26. 05 Sep, 2018 1 commit
  27. 27 Aug, 2018 1 commit
  28. 07 Aug, 2018 1 commit
  29. 31 Jul, 2018 1 commit
  30. 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
  31. 20 Jul, 2018 1 commit
    • 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