1. 28 Sep, 2020 1 commit
    • 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
  2. 22 Sep, 2020 1 commit
  3. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  4. 29 Apr, 2020 1 commit
  5. 09 Mar, 2020 2 commits
  6. 11 Feb, 2020 1 commit
  7. 03 Feb, 2020 1 commit
    • Sigurd Schneider's avatar
      [debugger] Allow termination-on-resume when paused at a breakpoint · 9e52d5c5
      Sigurd Schneider authored
      This CL implements functionality to allow an embedder to mark a
      debug scope as terminate-on-resume. This results in a termination
      exception when that debug scope is left and execution is resumed.
      Execution of JavaScript remains possible after a debug scope is
      marked as terminate-on-resume (but before execution of the paused
      code resumes).
      This is used by blink to correctly prevent resuming JavaScript
      execution upon reload while being paused at a breakpoint.
      
      This is important for handling reloads while paused at a breakpoint
      in blink. The resume command terminates blink's nested message loop
      that is used while to keep the frame responsive while the debugger
      is paused. But if a reload is triggered while execution is paused
      on a breakpoint, but before execution is actually resumed from the
       breakpoint (that means before returning into the V8 JavaScript
      frames that are paused on the stack below the C++ frames that belong
      to the nested message loop), we re-enter V8 to do tear-down actions
      of the old frame. In this case Runtime.terminateExecution() cannot be
      used before Debugger.resume(), because the tear-down actions that
      re-enter V8 would trigger the termination exception and crash the
      browser (because the browser expected the tear-down to succeed).
      
      Hence we introduce this flag on V8 that says: It is OK if someone
      re-enters V8 (to execute JS), but upon resuming from the breakpoint
      (i.e. returning to the paused frames that are on the stack below),
      generate a termination exception.
      
      We deliberated adding a corresponding logic on the blink side (instead
      of V8) but we think this is the simplest solution.
      
      More details in the design doc:
      
      https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk
      
      Bug: chromium:1004038, chromium:1014415
      
      Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66084}
      9e52d5c5
  8. 04 Dec, 2019 1 commit
    • Joyee Cheung's avatar
      [class] implement inspector support for private instance methods · 963ff849
      Joyee Cheung authored
      This patch implements inspector support for private instance methods:
      
      - Previously to implement brand checking for instances with private
        instance methods we store the brand both as the value with the brand
        itself as the key in the stances. Now we make the value the context
        associated with the class instead.
      - To retrieve the private instance methods and accessors from the
        instances at runtime, we look into the contexts stored with the
        brands, and analyze the scope info to get the names as well as
        context slot indices of them.
      - This patch extends the `PrivatePropertyDescriptor` in the inspector
        protocol to include optional `get` and `set` fields, and make the
        `value` field optional (similar to `PropertyDescriptor`s).
        Private fields or private instance methods are returned in the
        `value` field while private accessors are returned in the `get`
        and/or `set` field. Property previews for the instaces containing
        private instance methods and accessors are also updated similarly,
        although no additional protocol change is necessary since the
        `PropertyPreview` type can already be used to display accessors.
      
      Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
      
      Bug: v8:9839, v8:8330
      Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65337}
      963ff849
  9. 22 Oct, 2019 1 commit
  10. 16 Oct, 2019 1 commit
    • Simon Zünd's avatar
      Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" · 69efc4c3
      Simon Zünd authored
      This is a reland of 1c56974f
      
      This is a plain reland of the original CL. The original CL was speculatively
      reverted, but ended up not being the cause for bot failures.
      
      Original change's description:
      > Unconditionally enable snapshot builds and remove 'v8_use_snapshot'
      >
      > This CL removes 'v8_use_snapshot' and the usages of the implied
      > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the
      > "asan" variant instead of the now obsolete "no_snap" variant.
      >
      > Related chromium CL: https://crrev.com/c/1796325.
      >
      > Bug: v8:8531
      > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Reviewed-by: Nico Weber <thakis@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64290}
      
      TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org
      
      Bug: v8:8531
      Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64305}
      69efc4c3
  11. 15 Oct, 2019 2 commits
  12. 02 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Remove JS natives support, step 1 · 28a9dc2b
      Jakob Gruber authored
      The natives blob is deprecated and will be removed in the next
      release.
      
      This commit does two things, 1. it disables the v8_extra_library_files
      gn argument which will make building natives_blob.bin through gn
      impossible; 2. it marks API functions associated with the natives blob
      as V8_DEPRECATE_SOON.
      
      Embedders should remove any uses of SetNativesDataBlob and replace all
      calls to
      
       InitializeExternalStartupData(const char*, const char*)
      
      with the new function
      
       InitializeExternalStartupDataFromFile(const char*)
      
      Step 2 is to mark API functions as V8_DEPRECATED.
      Step 3, in the next V8 release, is to remove these functions and all
      other natives support in V8.
      
      Bug: v8:7624
      Change-Id: I745e96c60204a9b94d9240be65dd59bb9bdd0699
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1824944
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64080}
      28a9dc2b
  13. 11 Sep, 2019 1 commit
  14. 10 Sep, 2019 1 commit
  15. 28 Aug, 2019 1 commit
  16. 26 Aug, 2019 1 commit
  17. 23 Aug, 2019 1 commit
  18. 22 Aug, 2019 2 commits
  19. 09 Aug, 2019 1 commit
  20. 30 Jul, 2019 1 commit
  21. 28 Jun, 2019 1 commit
  22. 24 Jun, 2019 1 commit
    • Mathias Bynens's avatar
      [objects] Rename JSValue to JSPrimitiveWrapper · e428dfd7
      Mathias Bynens authored
      We currently use the class name “JSValue” for JSObjects that wrap
      primitive values. This name is a common source of confusion. This patch
      switches to a name that’s more clear.
      
      In addition to manual tweaks, the patch applies the following mechanical
      global replacements:
      
      before                          | after
      --------------------------------|--------------------------------------
      if_valueisnotvalue              | if_valueisnotwrapper
      if_valueisvalue                 | if_valueiswrapper
      js_value                        | js_primitive_wrapper
      JS_VALUE_TYPE                   | JS_PRIMITIVE_WRAPPER_TYPE
      JSPrimitiveWrapperType          | JSPrimitiveWrapper type
      jsvalue                         | js_primitive_wrapper
      JSValue                         | JSPrimitiveWrapper
      _GENERATED_JSVALUE_FIELDS       | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS
      
      Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62337}
      e428dfd7
  23. 17 Jun, 2019 1 commit
  24. 06 Jun, 2019 1 commit
  25. 31 May, 2019 1 commit
  26. 24 May, 2019 1 commit
  27. 23 May, 2019 3 commits
  28. 22 May, 2019 1 commit
  29. 21 May, 2019 1 commit
  30. 20 May, 2019 3 commits
  31. 17 May, 2019 1 commit
  32. 16 May, 2019 2 commits