1. 28 Sep, 2020 7 commits
    • evih's avatar
      Use js-to-wasm generic wrapper for f32 and f64 params · 4924d01f
      evih authored
      Currently, the generic wrapper is used for i32, i64, f32 and f64 params
      and 0 or 1 i32, i64, f32, f64 return value.
      
      Bug: v8:10701
      Change-Id: I3776de617aa4a384fdff5154ddad8ff405001a33
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429266
      Commit-Queue: Eva Herencsárová <evih@google.com>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70156}
      4924d01f
    • Marja Hölttä's avatar
      [ic] Add functions for printing out handlers · 01a8acb6
      Marja Hölttä authored
      Incl. random handler-related cleanups.
      
      Change-Id: I0a80e515c44aaf57a1834ee8ffa9cd47a31ea7be
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398518
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70155}
      01a8acb6
    • Dan Elphick's avatar
      [torque] Fix TestBitFieldStore reading wrong parameter · df0ea973
      Dan Elphick authored
      Fixes test-torque/TestBitFieldStore to read the Smi parameter passed in
      rather than the receiver which was always the global object.
      
      Change-Id: Ie6b343ad7ef9393c211b0e7c8e1b7c1427e0aeb4
      Bug: v8:10933
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434327
      Auto-Submit: Dan Elphick <delphick@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70154}
      df0ea973
    • Omer Katz's avatar
      cppgc: Add concurrent marking tests · be45cd8e
      Omer Katz authored
      Bug: chromium:1056170
      Change-Id: I2f62c74c3e435e05fd9e313af2f15925583872ab
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423716
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70153}
      be45cd8e
    • Alex Kodat's avatar
      [debug] Restore StepNext on correct frame for RestoreDebug · 9329f558
      Alex Kodat authored
      When an Isolate in a multi-threaded environment is being debugged
      and a thread does a Step Over (StepNext internally) one-shot
      breaks are created in the code at the stack frame where the
      StepNext occurred. However, if the stepped-over statement had
      a function call and the called function (or some function that
      it called) unlocked the Isolate (via a C++ function call) and
      another thread then locked the Isolate, an ArchiveDebug would
      be done which would save the fact that a StepNext is active and
      the call frame depth of the StepNext. The one-shot breaks would
      then be cleared to avoid stopping the now running thread.
      
      When the original thread that did the StepNext relocks the Isolate,
      a RestoreDebug is done which, seeing that a StepNext was active
      calls PrepareDebug which assumes that the StepNext must be for
      the current JS frame which is usually correct, but not in this
      case. This results in the StepNext break actually occurring in the
      function that called the C++ function not in the function where
      the StepNext was originally done. In addition, the function where
      the break now happens must necessarily be deoptimized if
      optimized, and debug code and a source map table created if one
      doesn't already exists though this is largely invisible to the
      user.
      
      Occasionally, a crash/core dump also occurs because the stack
      guard is restored after the debugging environment is restored in
      the RestoreThread code which can prevent the compiler from being
      called to generate the source map table (for the incorrect
      function) since the stack guard is another thread's stack guard,
      and so might appear that the stack guard has been gone past so
      the compiler is not called, resulting in there being no source
      map table. But PrepareStep ends up calling the BreakIterator
      (via the DebugInfo constructor) which assumes there is a source
      map table so we get a crash.
      
      The fix is to have PrepareStep to skip to the frame where the
      StepNext was done before doing its thing. Since the only
      PrepareStepcaller that requires a frame other than the current
      frame, is RestoreDebug, a target frame parameter was added to
      PrepareStep that's set by RestoreDebug and defaults to -1
      indicating to use the current frame for all other callers.
      
      While this made the order of the debug environment and stack
      guard no longer cause an obvious problem, it still felt wrong
      to defer restoration of the stack guard until after something
      as potentially complex as PrepareStep might be called, so the
      order of RestoreDebug and RestoreStackGuard calls were reversed.
      
      Bug: v8:10902
      Change-Id: I174e254e72414c827e113aec142f1d329ebe73d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405932
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70152}
      9329f558
    • Zhao Jiazhong's avatar
      [mips64][liftoff] Fix some memory access operations · 91619242
      Zhao Jiazhong authored
      MemOperand's immediate offset is int32_t value, but some offsets
      in liftoff are uint32_t, we should load the offsets to registers.
      
      And assemble instructions like lw/sw/daddiu could't handle operand
      with large immediate value. So we should use macro assemble instrs
      like Lw/Sw/Daddu instead, unless we can make sure the operands are
      proper for those assemble instructions.
      
      Bug: v8:10925
      Change-Id: I122d35a6857461791999b603f0150311bfc6343e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434985Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
      Cr-Commit-Position: refs/heads/master@{#70151}
      91619242
    • Omer Katz's avatar
      Reland "cppgc: Provide jobs support through DefaultPlatform and TestPlatform" · 905318c7
      Omer Katz authored
      This reverts commit 2221f090.
      
      Reason for revert: fix in patchset 2
      
      Original change's description:
      > Revert "cppgc: Provide jobs support through DefaultPlatform and TestPlatform"
      >
      > This reverts commit 22c0fc8f.
      >
      > Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8712?
      >
      > Original change's description:
      > > cppgc: Provide jobs support through DefaultPlatform and TestPlatform
      > >
      > > This CL extends cppgc::DefaultPlatform and TestPlatform to emulate
      > > jobs using std::thread and v8::base::Thread respectively.
      > > Jobs using these platform do not yield unless the job as been
      > > cancelled. Additionally, the job priority is ignored.
      > >
      > > Bug: chromium:1056170
      > > Change-Id: I72db1eef410d2be3d3e5ea7d4ece9e5584a451f2
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416378
      > > Commit-Queue: Omer Katz <omerkatz@chromium.org>
      > > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
      > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70139}
      >
      > TBR=mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
      >
      > Change-Id: Ic29235e3ab78a1b515a5b14b808e116a1ccffc0f
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: chromium:1056170
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432087
      > Reviewed-by: Francis McCabe <fgm@chromium.org>
      > Commit-Queue: Francis McCabe <fgm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70142}
      
      # Not skipping CQ checks because this is a reland.
      
      Bug: chromium:1056170
      Change-Id: Iaa8312da759ab97f646a9fb6144462a115393b5f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431666Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70150}
      905318c7
  2. 25 Sep, 2020 20 commits
  3. 24 Sep, 2020 13 commits