1. 24 Nov, 2021 1 commit
  2. 22 Nov, 2021 2 commits
  3. 09 Nov, 2021 1 commit
  4. 05 Nov, 2021 1 commit
  5. 02 Nov, 2021 1 commit
  6. 01 Oct, 2021 1 commit
  7. 19 Aug, 2021 1 commit
  8. 10 Aug, 2021 1 commit
    • Bruce Dawson's avatar
      Explicitly include windows.h in Win ARM64 files · 67a565c0
      Bruce Dawson authored
      Now that V8 doesn't globally include windows.h we need to explicitly
      include it in source files that need it. This fixes a Windows ARM64
      build break triggered by crrev.com/c/3042215.
      
      I did a test build of ARM64 V8 with and without this patch in order to
      reproduce the errors and confirm that there are no others.
      
      Bug: chromium:796644, chromium:1237067
      Change-Id: I43045fcaab9e6296629775a9705aae6b2066adef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3076019Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
      Auto-Submit: Bruce Dawson <brucedawson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76208}
      67a565c0
  9. 23 Jul, 2021 1 commit
  10. 21 Jul, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Add trap-handler support for arm64 simulator · e312038d
      Clemens Backes authored
      This adds a little {Simulator::ProbeMemory} method that is used from
      several places in the arm64 simulator to test if a memory address can be
      accessed, and trigger a signal from a specific location such that the
      trap-handler can handle it. In case of a trap, the simulator is
      redirected to the landing pad and stops executing the memory
      instruction that triggered the trap.
      
      Standard memory accesses and SIMD memory loads and stores are
      instrumented to probe the memory. This passes all existing tests. In
      case this CL misses certain spots, we can still add them later. This
      will not be a security problem, since we do not use the simulator in
      production.
      
      R=ahaas@chromium.org
      CC=mseaborn@chromium.org, v8-arm-ports@googlegroups.com
      
      Bug: v8:11955
      Change-Id: I52a81341e99fabc5fcf9e41ef4d8dd2226092803
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015557
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75843}
      e312038d
  11. 02 Jul, 2021 1 commit
  12. 10 Jun, 2021 1 commit
  13. 30 Apr, 2021 1 commit
  14. 22 Mar, 2021 1 commit
  15. 12 Mar, 2021 1 commit
    • Andreas Haas's avatar
      [wasm][liftoff][arm64] Avoid x28 even without pointer compression · 8d0f5a04
      Andreas Haas authored
      Due to a recent change Liftoff used different register configurations
      in the pointer-compression and no-pointer-compression setups. This
      caused a mismatch between the registers used by Liftoff and the
      registers spilled by the WasmDebugBreak builtin.
      
      With this CL the same register configuration is used both with and
      without pointer compression. Even without x28 there are 24 registers
      that can be used. Moreover, 24 registers can be spilled without
      padding, which would be needed with 25 registers to preserve stack
      alignment.
      
      Drive-by change: Use Reglist in frame-constants on all platforms.
      
      R=jkummerow@chromium.org
      
      Bug: v8:7581
      Change-Id: Iae2892718e905a7995a3fdd7be7fd4d75bebb3dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752884
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73366}
      8d0f5a04
  16. 15 Feb, 2021 1 commit
  17. 05 Feb, 2021 1 commit
  18. 02 Feb, 2021 2 commits
    • Leszek Swirski's avatar
      [arm64/sim] Add a simple backtrace debug command · 5a0b81b4
      Leszek Swirski authored
      Add a simple backtrace/bt command to the simulator debugger, which does
      the frame-pointer stack walk and dumps pc/fp/sp for each frame.
      
      This is strictly less powerful than the full JS stack dump, but can be
      used to debug issues with corrupted frames that prevent the JS stack
      dumper from working correctly.
      
      Change-Id: I26cc962ab8d22c0a219d6a35548544602aa89418
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2666688
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72480}
      5a0b81b4
    • Leszek Swirski's avatar
      [arm64/sim] Add a 'sim' gdb command · 1f72df06
      Leszek Swirski authored
      Extract out the command processing from Simulator::Debug(), and expose
      it to gdb as a new 'sim' command. Example usage:
      
          (gdb) sim p x15
          (gdb) sim stack
      
      The sim command will execute that one command, and will return to gdb.
      
      For a list of all commands, you can call
      
          (gdb) sim help
      
      Note that sim won't resume simulator execution until gdb continues
      execution; for example, `sim next` will set a breakpoint on the next
      instruction, and will return to gdb. The user then has to continue
      execution in gdb, at which point the simulator will break. The user can
      then re-enter gdb with the gdb command. This will look like this:
      
          (gdb) sim next
          (gdb) continue
          ...
          sim> gdb
          (gdb) ...
      
      Change-Id: I678e71e2642d8427950b5f7ed65890ceae69e18d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664448
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72479}
      1f72df06
  19. 29 Jan, 2021 1 commit
    • Ng Zhi An's avatar
      [arm64] Fix frame size to account for q registers · 45b99aaa
      Ng Zhi An authored
      In https://crrev.com/c/2645694 we push the full q registers before lazy
      compile, but we did not change the fixed frame size to account for the
      wider registers being pushed.
      
      This manifested in the frame having data like:
      
      (gdb) x/10xg start.ptr_
      0x7f5576ff3eb0: 0x0000000000000000      0x0000336b08202759
      0x7f5576ff3ec0: 0x7ff000007f801000      0x0000000000000000
      0x7f5576ff3ed0: 0x7ff000007f801001      0x0000000000000000
      0x7f5576ff3ee0: 0x7ff000007f801002      0x0000000000000000
      0x7f5576ff3ef0: 0x7ff000007f801003      0x0000000000000000
      
      The GC then walks part of this frame, thinking that 0x7ff000007f801003
      is a heap object, and then crashes.
      
      Add some static_asserts (similar to builtins-x64) to remind ourselves
      that the pushed registers have to match the size in frame constants.
      
      Bug: chromium:1161555,v8:11358
      Change-Id: Ic5138cc17ad44ccab9121ca226f9f812afef72c7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656857Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72439}
      45b99aaa
  20. 27 Jan, 2021 1 commit
  21. 19 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [arm][arm64] Use normal fp semantics in JSEntry · a016c9fe
      Seth Brenith authored
      On arm64, Windows Performance Recorder gets confused by the fact that fp
      in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the
      caller frame. The expected usage of fp is documented in [1]:
      
        The frame pointer (x29) is required for compatibility with fast stack
        walking used by ETW and other services. It must point to the previous
        {x29, x30} pair on the stack.
      
      In slightly more detail, the Windows function RtlWalkFrameChain is
      responsible for generating stack traces during profiling with Windows
      Performance Recorder, and that function relies on the rule quoted above.
      Notably, it does not make any effort to read the unwinding data that one
      could obtain with RtlLookupFunctionEntry. Stack walks using that data,
      such as those performed by WinDbg and the cctest StackUnwindingWin64,
      work fine.
      
      It would be convenient if we could use fp in a more standard way during
      JSEntry so that Windows profiling tools work correctly. (We can also
      reduce JSEntry by two instructions in doing so.)
      
      Both arm and arm64 currently put a -1 value on the stack at the location
      that fp points to. This could prevent accidental access during the
      epilog of JSEntry, where fp might be zero. However, we believe that this
      protection is no longer necessary, and any bug that causes a read from
      fp during the end of JSEntry would cause various CQ failures.
      
      [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160
      
      Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72165}
      a016c9fe
  22. 08 Jan, 2021 1 commit
  23. 24 Nov, 2020 1 commit
  24. 17 Nov, 2020 1 commit
  25. 03 Nov, 2020 1 commit
  26. 02 Nov, 2020 1 commit
  27. 19 Oct, 2020 1 commit
  28. 15 Oct, 2020 1 commit
  29. 23 Sep, 2020 1 commit
  30. 02 Sep, 2020 1 commit
  31. 19 Aug, 2020 1 commit
    • Salome Thirot's avatar
      [arm64] Implement list of allowed return addresses in the deoptimizer · 929dd374
      Salome Thirot authored
      When CFI is enabled this adds a check against this list whenever a new
      return address must be set in a deoptimized frame, as a mitigation for
      ROP attacks.
      The list is known at linking time so that its content and the pointer
      to it can be stored in a read-only memory section.
      The check is performed in the signing function, which is no longer
      generic, as well as when setting the current pc of the frame.
      Since the pc is now only signed when setting the caller's pc, there
      is no need for ReplaceContext anymore.
      
      Bug: v8:10026
      Change-Id: I5e85a62b94722051716fdeba476db383c702a318
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287490Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
      Cr-Commit-Position: refs/heads/master@{#69478}
      929dd374
  32. 22 Jun, 2020 1 commit
  33. 16 Jun, 2020 1 commit
  34. 09 Jun, 2020 1 commit
  35. 17 Mar, 2020 1 commit
  36. 16 Mar, 2020 2 commits
    • Clemens Backes's avatar
      [wasm] Load register values from DebugBreak frame · ae03752f
      Clemens Backes authored
      This implements inspection of live registers on breakpoints in Liftoff.
      To that end, the frame pointer of the WasmDebugBreak frame is remembered
      when iterating the stack. Based on a platform-specific implementation of
      {WasmDebugBreakFrameConstants}, the offset of the respective register
      within that frame is computed, and the value is read from the frame.
      
      As a drive-by, the wasm debug side table is storing register codes as
      liftoff codes, which can also store register pairs (needed for i64 on
      32-bit platforms, and for SIMD, which is not supported yet).
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66719}
      ae03752f
    • Clemens Backes's avatar
      [wasm] Fix registers spilled in DebugBreak frame · e47f9a9d
      Clemens Backes authored
      The set of registers to spill was wrong. Instead of spilling wasm
      parameter registers (like the WasmCompileLazy builtin), we should spill
      all registers that are being used as Liftoff cache registers.
      This CL defines platform-specific WasmDebugBreakFrameConstants which
      hold the set of registers to spill. This set is used in the builtin, and
      will later be used for inspecting the spilled registers.
      
      In order to iterate bit sets more easily in both direction (MSB to LSB
      or LSB to MSB), we add a base::bits::IterateBits{,Backwards} method
      which provides the respective iterators.
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I73ecbdff9b29e244c478b404063c0c9ee25bc821
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102570Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66715}
      e47f9a9d
  37. 20 Feb, 2020 1 commit