1. 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
  2. 25 Oct, 2019 2 commits
  3. 19 Sep, 2019 1 commit
    • Jakob Gruber's avatar
      [build] Define V8_TARGET_OS_ and consider it in x64 codegen · 99d31b43
      Jakob Gruber authored
      This CL allows us to distinguish between the host- and target OS. The
      host OS is defined by V8_OS_ macros (e.g. V8_OS_WIN). The target OS is
      defined by V8_TARGET_OS_ macros (e.g. V8_TARGET_OS_WIN).
      
      V8_TARGET_OS_ macros are defined by gn, based on the `target_os` gn
      variable. If a V8_TARGET_OS_ is set, we also define V8_HAVE_TARGET_OS
      (this determines fall-back behavior in V8; if it is not defined, we set
      V8_TARGET_OS_ to equal the equivalent V8_OS_ define).
      
      Besides adding the defines, this CL also adds logic to consider the
      target OS in codegen. Specifically, x64 builds now look at the
      V8_TARGET_OS_WIN define instead of V8_OS_WIN or _WIN64. This
      effectively makes cross-compilation to x64 Windows in mksnapshot
      possible.
      
      In future work, we could add similar support for cross-compiling to
      other platforms such as ia32 Windows.
      
      Bug: v8:9736,chromium:803591
      Change-Id: I689f3de8c206b743c4bef703f5ade0bba32ce995
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809374Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63892}
      99d31b43
  4. 12 Jul, 2019 1 commit
  5. 28 May, 2019 1 commit