1. 05 Aug, 2021 1 commit
    • Jakob Gruber's avatar
      Don't attempt to create source positions for unfinalized scripts · 4371d88d
      Jakob Gruber authored
      For streaming compilation, scripts don't have a source string attached
      until finalization, but the Script and SharedFunctionInfo objects are
      already on the heap and may be picked up by heap walks.
      
      This happens e.g. in CollectSourcePositionsForAllBytecodeArrays, where
      we then try to reparse and recompile the SFI. This is invalid, since
      the source string is not yet set.
      
      Avoid this by checking for the empty source string (and leaving a TODO
      for a nicer future solution).
      
      Bug: v8:12051
      Change-Id: Ib4f40cd218151120e5aff8558dd5df5c8834412e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071403
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76104}
      4371d88d
  2. 04 Aug, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Fix positions for inline scripts with #sourceURL. · c2f30c2b
      Benedikt Meurer authored
      For inline scripts that have a `// #sourceURL=foo.js` annotation, the
      V8 inspector (and by extension `Error.stack`) currently operates in
      terms of the `foo.js`, i.e. doesn't give any hint about the actual
      source, except for the line/column offsets reported upon scriptParsed.
      However in case of stack frames (i.e. as part of `Error.stack` or as
      part of the call frames reported via CDP), the line/column offsets are
      relative to the actual source instead of relative to the `foo.js` part,
      which - besides other things - makes post-processing of recorded stack
      traces tricky (sometimes impossible).
      
      This change adjusts the source positions reported for (inline) scripts
      with sourceURL annotations to be relative to the (inline) script instead
      of the surrounding document.
      
      Bug: chromium:1183990
      Fixed: chromium:578269
      Change-Id: I74f2b93c22ec43ca796b6b51faa9df5b99cf03f9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069289
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76097}
      c2f30c2b
  3. 12 Apr, 2021 1 commit
  4. 16 Mar, 2021 1 commit
  5. 12 Feb, 2021 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Implement instrumentation breakpoints · 15f3392a
      Clemens Backes authored
      This CL adds support for instrumentation breakpoints in wasm. The
      request for "break on entry" is set on the script, and we need to keep
      it stored there because there might not be any instances of that wasm
      module yet. Once instances get created, the flag value is transferred to
      all instances. The flag stored there is then checked in the function
      prologue in Liftoff debugging code. This ensures that we will stop at
      the first valid break position in any function within that module.
      Hitting that instrumentation breakpoint will then clear the flag from
      the script and from all other live instances (in the same isolate).
      
      A first basic test is contained in this CL. More tests will be added
      later.
      
      R=thibaudm@chromium.org, bmeurer@chromium.org
      
      Bug: chromium:1151211
      Change-Id: I5442d4044934988269becececc03699b850d51d7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690588Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72701}
      15f3392a
  6. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  7. 03 Aug, 2020 1 commit
  8. 29 May, 2020 1 commit
  9. 26 May, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque][cleanup] Use more precise field types in a few classes" · 16cb2d94
      Seth Brenith authored
      This reverts commit 4e5fabae.
      
      Reason for revert: performance regressions chromium:1085305, chromium:1084978
      
      Original change's description:
      > [torque][cleanup] Use more precise field types in a few classes
      > 
      > This change updates some Torque-defined classes to include more precise
      > field types where possible. It also updates those classes to use
      > @generateCppClass. One field was removed because it's unused
      > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo
      > actually became less precise because they're based on Script::name,
      > which is an embedder-provided untyped Local<Value>. (Automatically
      > generated accessors pointed out this bug easily.)
      > 
      > This change also includes a couple of minor fixes in Torque.
      > 
      > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67907}
      
      TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67972}
      16cb2d94
  10. 19 May, 2020 1 commit
  11. 06 Nov, 2019 1 commit
    • Simon Zünd's avatar
      Introduce REPL mode · fbcc2e87
      Simon Zünd authored
      Design doc: bit.ly/v8-repl-mode
      
      This CL adds a new REPL mode that can be used via
      DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration
      of 'let' bindings at the moment. Example:
      
      REPL Input 1: let x = 21;
      REPL Input 2: let x = 42;
      
      This would normally throw a SyntaxError, but works in REPL mode.
      
      The implementation is done by:
        - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo}
          and script {Scope}.
        - Each global let declaration still gets a slot reserved in the
          respective {ScriptContext}.
        - When a new REPL mode {ScriptContext} is created, name clashes
          for let bindings are not reported as errors.
        - Declarations, loads and stores for global let in REPL mode are
          now "load/store global" instead of accessing their respective
          context slot directly. This causes a lookup in the ScriptContextTable
          where the found slot for each name is guaranteed to be the same
          (the first one).
      
      Bug: chromium:1004193, chromium:1018158
      Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64793}
      fbcc2e87
  12. 10 Oct, 2019 1 commit
  13. 09 Oct, 2019 1 commit
  14. 18 Sep, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Make {Script} object reference {NativeModule} directly. · 9d8aa1a6
      Michael Starzinger authored
      This is a first step towards being able to share the same script for
      multiple {WasmModuleObject} objects. In general it should be possible
      for the inspector to debug (i.e. disassemble, set breakpoints) multiple
      modules if they all have the same URL (and the same wire bytes). These
      are the same conditions under which we can canonicalize the modules to
      be based on the same underlying {NativeModule} as well. Hence it makes
      sense to establish a link from {Script} to {NativeModule} in this CL.
      
      Subsequent CLs will eventually deprecate the {wasm_module_object} field.
      
      R=clemensh@chromium.org
      BUG=v8:6847
      
      Change-Id: I5cfb617e18d9b06682e6437b2a2146ea5665c1c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807371
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63859}
      9d8aa1a6
  15. 23 May, 2019 1 commit
  16. 08 Mar, 2019 1 commit
  17. 09 Jan, 2019 1 commit
  18. 26 Dec, 2018 1 commit
  19. 18 Dec, 2018 1 commit
  20. 17 Dec, 2018 1 commit
  21. 29 Nov, 2018 1 commit
  22. 28 Nov, 2018 1 commit
  23. 27 Nov, 2018 1 commit
  24. 25 Nov, 2018 1 commit
  25. 05 Nov, 2018 1 commit
  26. 05 Jul, 2018 1 commit
  27. 04 May, 2018 1 commit
  28. 27 Apr, 2018 1 commit
  29. 19 Mar, 2018 1 commit
  30. 13 Mar, 2018 2 commits
  31. 18 Dec, 2017 1 commit
  32. 13 Oct, 2017 1 commit
  33. 31 Aug, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [Modules] Introduce ScriptOrModule and HostDefinedOptions · dbfe4a49
      Sathya Gunasekaran authored
      This patch introduces a new container type ScriptOrModule which
      provides the name and the host defined options of the script/module.
      
      This patch also introduces a new PrimitivesArray that can hold
      Primitive values, which the embedder can use to store metadata.
      
      The HostDefinedOptions is passed to V8 through the ScriptOrigin, and
      passed back to the embedder through HostImportModuleDynamically for
      module loading.
      
      Bug: v8:5785, v8:6658, v8:6683
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I56c26fc9a680b273ac0a6691e5ad75f15b8dc80a
      Reviewed-on: https://chromium-review.googlesource.com/622158Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47724}
      dbfe4a49
  34. 30 Jun, 2017 1 commit
  35. 12 Jun, 2017 1 commit
  36. 30 May, 2017 1 commit