1. 24 Jul, 2020 1 commit
  2. 26 Jun, 2020 1 commit
  3. 12 Jun, 2020 1 commit
  4. 03 Jun, 2020 1 commit
  5. 29 May, 2020 1 commit
  6. 31 Mar, 2020 1 commit
  7. 16 Mar, 2020 3 commits
    • Milad Farazmand's avatar
      PPC/s390: [wasm] Load register values from DebugBreak frame · fcf5d2a7
      Milad Farazmand authored
      Port ae03752f
      
      Original Commit Message:
      
          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=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I1f4a52c349bd57098f633c5fd641642695b6fe96
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106294Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66737}
      fcf5d2a7
    • Milad Farazmand's avatar
      PPC/s390: [wasm] Fix registers spilled in DebugBreak frame · e54259ee
      Milad Farazmand authored
      Port e47f9a9d
      
      Original Commit Message:
      
          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=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ic308a7712f080e43a0c45f496b087ce8450f657a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105563Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66736}
      e54259ee
    • Milad Farazmand's avatar
      s390: [wasm-simd] Add simulator support for simd operations · 1b2e0ddf
      Milad Farazmand authored
      Change-Id: I0352ef9e4213d6dc0f50a5406d8e167784408452
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095755
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66731}
      1b2e0ddf
  8. 02 Mar, 2020 1 commit
  9. 18 Feb, 2020 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [simulator] Add a new command to the debugger to dump memory. · 45f1ec5d
      Milad Farazmand authored
      Port 820faa6e
      
      Original Commit Message:
      
          The arm/arm64 simulators debugger has a command "mem" that prints
          the content of the memory. It also prints a short summary for JS
          objects (SMI, Array, JSFunction, ...). That is very handy, but
          when trying to print incomplete initialized memory, it could raise
          an exception.
      
          It is useful to have a command that prints the content of the memory
          for non-initialized or bogus values without the risk of raising
          an exception. This CL adds the command "dump".
      
      R=victorgomes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ie3931af0cf34052706618774ba95bf0057cfcabf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062159Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66308}
      45f1ec5d
  10. 31 Jan, 2020 1 commit
  11. 30 Jan, 2020 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [arm32] Fix breakpoints in simulator/debugger · 19bc0ea2
      Milad Farazmand authored
      Port e920b2e3
      
      Original Commit Message:
      
          - Debugger stepping assumes that the pc points to the instruction
            that should get executed next, so we need to increment it when
            we hit a stop or a bkpt instruction or else we'll end up in an
            infinite loop.
          - The "break" and the "stop unstop" command write into code space, so
            they need to temporarily make code space writable or else they
            just crash. (Note that this doesn't work for embedded builtins.)
      
      R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I1a9507f621c83dd94f2de230f7c75bc1fee95dd0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031204Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66057}
      19bc0ea2
  12. 25 Oct, 2019 2 commits
  13. 30 Sep, 2019 1 commit
  14. 14 Aug, 2019 1 commit
  15. 22 Jul, 2019 1 commit
  16. 17 Jul, 2019 2 commits
  17. 04 Jul, 2019 2 commits
  18. 29 May, 2019 1 commit
  19. 28 May, 2019 1 commit