- 01 Oct, 2021 2 commits
-
-
Benedikt Meurer authored
The logic to locate the correct function to set a breakpoint in based on script position was treating SharedFunctionInfo::EndPosition() as inclusive rather than exclusive. There are various assumptions all over the Debugger that seem to demand this treatment for the toplevel script. But it's definitely wrong for function literals. Fixed: chromium:1253277 Change-Id: I3421703673f4d78aee28e923e03e2fca24bc06ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197715 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77186}
-
Benedikt Meurer authored
Previously we'd treat %_AsyncFunctionReject (and %AsyncFunctionReject) as side-effect free (in async functions), but that's not correct, since promise rejections have side-effects (at the very least triggering the unhandled promise rejection machinery in the browser). This required a minor refactoring as previously we'd classify functions as side-effecting or not depending on whether they contain any calls to side-effecting intrinsics, no matter whether this call is actually executed or not. That would break REPL mode however if we'd generally treat all async functions with %_AsyncFunctionReject intrinsic calls as side-effecting, so instead of performing the intrinsic checks ahead of time, we now perform the test at execution time. Before: https://imgur.com/5BvJP9d.png After: https://imgur.com/10FanNr.png Fixed: chromium:1249275 Change-Id: Ib06f945ba21f1e06ee9b13a1363fad342464fd9a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197712 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#77183}
-
- 20 Sep, 2021 1 commit
-
-
Igor Sheludko authored
... and move methods that use XXX::cast() there. This will untangle the include cycle that'll happen in a follow-up CLs. Bug: v8:11880 Change-Id: Iba46bc9b0e0df9530197f57d0469456eb9006e66 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3164456Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76932}
-
- 06 Sep, 2021 1 commit
-
-
Leszek Swirski authored
Remove the BaselineData intermediate structure for baseline code, and write the baseline Code object into the SharedFunctionInfo directly. We still need a pointer to the BytecodeArray/InterpreterData, so re-use the Code object's deoptimization data slot for this (baseline code doesn't have deoptimization data). A consequence of this is that the BytecodeArray pointer becomes immutable when there is baseline code. This means that we cannot install a debug BytecodeArray while baseline code is active (we have to flush it first), and we can't tier-up code with debug BytecodeArray to baseline. Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76675}
-
- 24 Aug, 2021 1 commit
-
-
Jakob Gruber authored
.. from a StackTraceFrameIterator (STFI). This replaces the (incorrect) pattern StackTraceFrameIterator it(isolate); FrameSummary fs = FrameSummary::GetTop(it.javascript_frame()); The STFI has filtering semantics that only iterate over certain JS and Wasm frames. These semantics (e.g. skipping over frames that are not subject to debugging) must be preserved when looking into inlined optimized frames. The new convenience function GetTopValidFrame encapsulates this logic. Bug: chromium:1237730 Change-Id: I060b36b5ac6a5decef90da4de45e679516ff93fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3110611Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#76445}
-
- 05 Aug, 2021 1 commit
-
-
Jakob Gruber authored
Optimizing compilation can no longer collect source positions on demand since it may now run concurrently without serialization. Instead, we now collect full source positions when any component that needs them is enabled (profiler, debugger). Bug: v8:7790,v8:12030 Change-Id: I6a2a82eb2b0d3e92121e101b4d9bf330c1f6c065 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067226Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76114}
-
- 22 Jul, 2021 1 commit
-
-
Camillo Bruni authored
* Avoid accessing thread_local_top directly and use getters: - scheduled_exception - pending_exception - pending_message * Rename pending_message_obj to pending_message Bug: chromium:1014421 Change-Id: I080b7d5919e180a943776c79ee9321235d58d3c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010278Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#75864}
-
- 19 Jul, 2021 1 commit
-
-
Mythri A authored
This is in preparation for baseline code flushing. After a deopt we choose to execute baseline or bytecode based on whether SharedFunctionInfo has any baseline code. With baseline code flushing, it is possible that baseline code is flushed after this point and before we start executing the unoptimized code (for ex: materializing objects). To handle such situations this CL updates the BaselineEnterAt* builtins to check for baseline code and restart either at baseline / bytecode. Bug: v8:11947 Change-Id: I2084e38196c882f802d1186ff8c9ab881a35b16b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3030711 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75783}
-
- 14 Jul, 2021 1 commit
-
-
Benedikt Meurer authored
Previously we had passed kOnEntryBreakpointPosition as a marker through the regular SetBreakPointForScript() logic and handled that specially in WasmScript, however this instrumentation breakpoint is special and gets in the way of returning more information about a regular breakpoint in case of crbug.com/700516, so I decided to just isolate that into it's own method, especially since the only user already special-cases Wasm anyways. Bug: chromium:1162229, chromium:700516 Change-Id: Ie7966c1701365a4b03710d6dc32cc8278577ee3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026711 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#75724}
-
- 07 Jul, 2021 1 commit
-
-
Jesper van den Ende authored
This allows for marking promises as silent. Setting this flag prevents the debugger from pausing when the promise rejects. Bug: chromium:1132506 Change-Id: I260e52faa45ebedd9e8d84e092bd0260e828a902 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001354Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#75595}
-
- 06 Jul, 2021 1 commit
-
-
Camillo Bruni authored
Add and use two new RCS scopes: - RuntimeCallCounterId::kDebugger - RuntimeCallCounterId::kDebuggerCallback Change-Id: Ifd326424248948d0d5c1e0e29cacaecc92046e88 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3006415Reviewed-by: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#75583}
-
- 05 Jul, 2021 2 commits
-
-
Yang Guo authored
Bug: none Change-Id: I634631515e392198c5a6c885ab033035ead97f25 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003468Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#75563}
-
Yang Guo authored
Bug: none Change-Id: I95060382c0e10a252f1cec7b2d2c4b44f757b5f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003154 Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#75552}
-
- 01 Jul, 2021 1 commit
-
-
Peter Kasting authored
There are still a few cases remaining that seem more controversial; I'll upload those separately. Bug: chromium:1066980 Change-Id: Iabbaf23f9bbe97781857c0c589f2b3db685dfdc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994804 Commit-Queue: Peter Kasting <pkasting@chromium.org> Auto-Submit: Peter Kasting <pkasting@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#75494}
-
- 22 Jun, 2021 1 commit
-
-
Benedikt Meurer authored
When looking up the break index for a given source position, default to the last break index if there is neither a precise match nor a breakable position after the source position (in which case we still pick the first candidate). Fixed: chromium:1222065 Bug: chromium:901819, chromium:782461, chromium:1222060 Change-Id: I10d6a086b2d5fadc9e6dca0c49ed4187eb0359ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972917 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#75284}
-
- 14 Jun, 2021 1 commit
-
-
Camillo Bruni authored
- Convert Builtin to enum class - Change int-based builtin_index methods to use Builtin - Change Builtins::builtin to Builtins::code Change-Id: Id9e3bb83da97e8894ca7ca78e1e852da60675619 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949104 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75127}
-
- 10 Jun, 2021 1 commit
-
-
Benedikt Meurer authored
This change addresses inconsistencies wrt. to stepping into generator functions and breaking on the implicit initial yield. The new behavior is the following: 1. Stepping into a generator function doesn't trigger "generator stepping", but rather pauses right before the initial yield (assuming there a no non-simple parameters in between). 2. When paused on the initial yield and stepping into or over, we also don't turn on "generator stepping" immediately, but rather return to the caller and only enter "generator stepping" on SuspendGenerator bytecodes that correspond to `yield`s or `await`s in the source code. This matches the stepping behavior of regular functions more closely and seems like a good compromise. Fixed: chromium:901814 Change-Id: Ifc6c174011df1afea183e2c6ec21de27d72b17a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949099 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#75066}
-
- 07 Jun, 2021 1 commit
-
-
Camillo Bruni authored
- Add new Builtin enum - Move Builtins::Name:kXXX to Builtin::kXXX - Update existing code Follow CLs will unify the mix of using int builtin-ids and Builtins::Name to only use the new Builtin enum and changing it to an enum class. Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#74995}
-
- 01 Jun, 2021 1 commit
-
-
Benedikt Meurer authored
In the Chrome DevTools Protocol, the step actions are named StepOut, StepOver, and StepInto, but internally we used StepOut, StepNext, and StepIn instead. This change adjusts the naming to be consistent. Bug: chromium:901814, chromium:1162229 Change-Id: Id3502a1b0a4aadd94734ec3d1fef73c1782fa220 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928510Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74877}
-
- 10 May, 2021 2 commits
-
-
Benedikt Meurer authored
The FrameSummary::FunctionName() method is only used by the FrameInspector in the debugger, so the natural place to put the dependency on GetWasmFunctionDebugName() is in there, rather than adding a new dependency to frames.cc. This is a follow up cleanup as discussed in https://crrev.com/c/2878734 Bug: chromium:1159307 Change-Id: I0698adf63f88fe6a93d6e5e6235bc0c2219e9341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883784Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#74482}
-
Nico Hartmann authored
Torque-generated relaxed/acquire/release accessors now expect an additional Tag argument to be more consistent with handwritten accessors. Torque's annotations are renamed from @relaxedRead, @relaxedWrite, @acquireRead and @releaseWrite to @cppRelaxedLoad, @cppRelaxedStore, @cppAcquireLoad and @cppReleaseStore, repesectively. This renaming shall better reflect the fact that those annotations just generate corresponding synchronization on the generated C++ accessors (not CSA code) and be more consistent with the C++ side of things where "Load" and "Store" is used instead of "Read" and "Write". This CL uses these new annotations on a few fields in DebugInfo and FunctionTemplateInfo to have Torque generate accessors automatically. Bug: v8:11122 Change-Id: Ibdf3e6b37a254605ff69ba9a50d7b1646790ea15 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876857Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#74463}
-
- 29 Apr, 2021 1 commit
-
-
Benedikt Meurer authored
The "Restart frame" feature was implemented as part of LiveEdit and primarily used to support LiveEdit of active functions, but that was previously disabled as part of https://crrev.com/c/2846892 because it's too brittle and causes crashes when using seemingly unrelated features. The "Restart frame" feature was also available as a context menu item separately in the DevTools front-end, but that was also already removed as part of https://crrev.com/c/2854681 earlier. So all uses are gone now. This change works by marking Debugger.restartFrame as deprecated and having it respond with a ServerError all the time. It thus allows us to remove a whole bunch of machinery that was essentially just put in various places to support the restart_fp_ magic. In particular the debugger no longer needs any machine specific builtins now. Bug: chromium:1195927 Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484 Fixed: chromium:1203606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#74276}
-
- 23 Apr, 2021 1 commit
-
-
Patrick Thier authored
We could end up in a baseline entry trampoline without having baseline code, because of an unhandled interaction in the debugger (discarding baseline code) and the deoptimizer. Bug: chromium:1199681 Change-Id: Ia33bb4d64903dd989728465b3d83a88b84597a8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843820Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#74153}
-
- 19 Apr, 2021 1 commit
-
-
Patrick Thier authored
Rename - InterpreterEnterBytecodeDispatch to InterpreterEnterAtBytecode - InterpreterEnterBytecodeAdvance to InterpreterEnterAtNextBytecode. The reason for renaming is consistency with baseline trampolines that have similar functionality, but the old names didn't fit for baseline very well. Change-Id: I35897972fdd71f3bb0db74820db2b9034144a3c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2830794Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#74027}
-
- 12 Apr, 2021 1 commit
-
-
Marja Hölttä authored
The de-duplication happens when 1) we have a JSFunction for an outer function and a JSFunction for its inner function in the snapshot and 2) we call the outer function again after deserializing Expectation: the created JSFunction for the inner function uses the SFI which was created when deserializing. Bug: v8:11525 Change-Id: I80933514873e857452585317248fa34913d8d8e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794438Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#73900}
-
- 22 Mar, 2021 1 commit
-
-
Kim-Anh Tran authored
This fixes a bug in which CompileTopLevel has a pending exception that is never taken care of. This CL adds a check for the output of CompileTopLevel and clears the pending exceptions if existent. Also-by: bmeurer@chromium.org Bug: chromium:1190290 Change-Id: Ieba537d5af78fc35475f9547c240c70850bea608 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773346 Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73561}
-
- 16 Mar, 2021 1 commit
-
-
Clemens Backes authored
This removes the TYPE_WASM script type, and all fields on Script that are only needed for WebAssembly. R=jgruber@chromium.org Bug: v8:11238 Change-Id: I233bfd3dec9b389bc74d926670310fd175c0c6d8 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2757690Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73418}
-
- 15 Mar, 2021 1 commit
-
-
Kim-Anh Tran authored
This changes the behavior of SetBreakpointForScript to find more accurate break positions. Previously, setting a breakpoint would only consider the shared function info that contained the requested position for setting a breakpoint. More intuitively, a breakpoint should not necessarily be set in a function that contains the position, but in the closest breakable location that comes after the position we requested. To achieve this we: 1. find the shared function info of the inner most function that contains the requested_position. This function's end position is used to find other shared function infos in step 2. 2. search for all shared function infos that intersect with the range [requested_position, inner_most_function.break_position[. 3. From the shared function infos extracted in 2, find the one that has the closest breakable location to requested_position. Also-By: bmeurer@chromium.org Fixed: chromium:1137141 Change-Id: I4f4c6c3aac1ebea50cbcad9543b539ab1ded2b05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742198 Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73392}
-
- 11 Mar, 2021 3 commits
-
-
Clemens Backes authored
This is a reland of 80f5dfda. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
-
Clemens Backes authored
This reverts commit 80f5dfda. Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} Bug: v8:11238 Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866 Auto-Submit: Clemens Backes <clemensb@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#73346}
-
Clemens Backes authored
This is the biggest chunk, including - all of src/wasm, - torque file for wasm objects, - torque file for wasm builtins, - wasm builtins, - wasm runtime functions, - int64 lowering, - simd scala lowering, - WasmGraphBuilder (TF graph construction for wasm), - wasm frame types, - wasm interrupts, - the JSWasmCall opcode, - wasm backing store allocation. Those components are all recursively entangled, so I found no way to split this change up further. Some includes that were recursively included by wasm headers needed to be added explicitly now. backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc because it only tests wasm backing stores. This file is excluded from no-wasm builds then. R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org Bug: v8:11238 Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73344}
-
- 08 Mar, 2021 1 commit
-
-
Kim-Anh Tran authored
This fixes a null pointer access in FindSharedFunctionInfo that was introduced when adding a guard to top level function compilation. Bug: chromium:1185540 Change-Id: I24b9752637aba0e660bd8f20be83522e1009b69f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742194 Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73258}
-
- 03 Mar, 2021 1 commit
-
-
Benedikt Meurer authored
When retrieving an API accessor function (i.e. either the getter or the setter) for which the lazy accessor mechanism is used (i.e. where the actual JSFunction is created lazily and only the FunctionTemplateInfo) is around, we thus far created a fresh JSFunction every time the accessor function is requested, but that's observably wrong behavior, since the accessors are JavaScript objects with identity. We currently rely on the instantiation cache to guarantee identity, but there's no reason why we couldn't instead just put the instantiated JSFunction into the AccessorPair. Fixing this to only instantiate the lazy accessor pair only once, upon first time it's requested, coincidentally also simplifies (and fixes) the API accessor breakpoint machinery. This was previously lacking support for walking dictionary prototype objects and forcibly instantiating the lazy accessor pairs with break points. However, all this magic in the debugger is no longer necessary when we ensure that the lazy accessor pair component is generally only instantiated once. Bug: v8:178, v8:7596, chromium:986063, chromium:496666 Change-Id: I41d28378010716c96c8ecf7c3f1247765f8bc669 Fixed: chromium:1163547 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731527Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73163}
-
- 02 Mar, 2021 2 commits
-
-
Clemens Backes authored
This removes all wasm includes from src/debug and src/inspector if webassembly is disabled (v8_enable_webassembly=false). It also removes the definition of {WasmValueObject} and {v8::debug::WasmScript}. This will allow to later fully exclude the src/wasm directory from compilation (once other components are fixed). R=bmeurer@chromium.org, machenbach@chromium.org Bug: v8:11238 Change-Id: I41a1d83d01fbb6c015cdfd6cc063bad90052505d Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726506Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73138}
-
Benedikt Meurer authored
Be explicit about source positions for `Return`s in the BytecodeGenerator, and only do self-healing explicitly in the `ReturnStatement` translation, where an end position of `kNoSourcePosition` is turned into the return position of the function literal. This allows us to reason more easily about which `Return`s actually receive a meaningful source position, and in particular it allows us to construct the internal `Return`s for `yield` and `yield*` with no source position attached to them. Previously they'd get the source position for the implicit (final) return attached to it, which confused the debugger and led to breakpoints being set in the completely wrong spot. Considering the simplified example ``` function* foo(){ var a = 1; } ``` this would previously generate the following bytecode ``` 0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 } 4 : Mov <closure>, r2 7 : Mov <this>, r3 13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3 14 : Star0 13 E> 15 : SuspendGenerator r0, r0-r1, [0] 20 : ResumeGenerator r0, r0-r1 24 : Star2 25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0 29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 } 33 : Ldar r2 13 E> 35 : Throw 36 : Ldar r2 30 S> 38 : Return <=========================== internal Return 27 S> 39 : LdaSmi [1] 41 : Star1 42 : LdaUndefined 30 S> 43 : Return ``` where everything between offset 4 and 42 corresponds to the implicit yield at the beginning of every generator function, in particular the code between 20 and 42 corresponds to that initial yields resumption logic. Notice how the internal Return at offset 38 gets assigned the source position of the function literal (the same as the implicit return at the end). This confuses the debugger quite a bit when trying to set a breakpoint on the closing brace, since it's going in bytecode order and will thus discover the `Return` at offset 38 first (matching the source position 30 it's currently looking for) and setting the breakpoint there. This `Return` bytecode however is only executed when the generator is resumed via `GeneratorPrototype.return()`, and it'll not hit when the developer uses the generator normally, which is not the desired behavior and extremely confusing (especially since stepping on the other hand works as expected). With this patch, we no longer slap a source position (and in particular not the function literal's return position) onto these internal `Return`s as you can see from the generated bytecode below: ``` 0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 } 4 : Mov <closure>, r2 7 : Mov <this>, r3 13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3 14 : Star0 13 E> 15 : SuspendGenerator r0, r0-r1, [0] 20 : ResumeGenerator r0, r0-r1 24 : Star2 25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0 29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 } 33 : Ldar r2 13 E> 35 : Throw 36 : Ldar r2 38 : Return 27 S> 39 : LdaSmi [1] 41 : Star1 42 : LdaUndefined 30 S> 43 : Return ``` This also allows us to remove the break position finding hack that was kept in BreakIterator::BreakIndexFromPosition() for generators and modules. Fixed: chromium:901819 Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73119}
-
- 24 Feb, 2021 2 commits
-
-
Kim-Anh Tran authored
This adds a re-compilation of top level functions in getPossibleBreakpoints if no candidates could be found. This step is necessary as the GC may remove SharedFunctionInfo about top-level functions. Bug: chromium:1137141 Change-Id: I8830438d78751ba318d65f43d790ee98f306a57e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696154Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#73008}
-
Georg Neis authored
It had essentially become a synonym for BytecodeArrayAccessor. This removes the BytecodeArrayIterator class and renames BytecodeArrayAccessor to BytecodeArrayIterator. Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#73005}
-
- 23 Feb, 2021 1 commit
-
-
Leszek Swirski authored
Baseline code is, like baseline frames, now considered unoptimized, sharing this name with interpreted code. Bug: v8:11420,v8:11429 Change-Id: If1f4a41725dd0d809a4412f5d2f827d19f9628fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713102 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72959}
-
- 17 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
In case there's no exact match for the breakable location in SetBreakpoint(), don't try to find the syntactically closest break location, but rather find the first possible break location in bytecode order. In particular when trying to set a breakpoint in a line with for-of or an array destruction, there's no point in going for the syntactically closest to the beginning of the line, but rather go for the semantically first, as the intiution for setting a breakpoint on a line is that the debugger stops before it executes anything on said line. In the example ``` var [^a, ^b] = ^func(); ``` there are three possible break locations, and the correct one is the last one as the call to func will happen first at runtime. For generators that's currently broken because of the implicit initial yield, and same with modules (see crbug.com/901819), so we keep the previous behavior of finding the closest breakable location, and will fix that independently in a follow up CL. Bug: chromium:901819 Fixed: chromium:782461 Also-By: yangguo@chromium.org Change-Id: Ie724c5cb08e5f4edd90a450d99e001dff06bbe7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696586 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72813}
-
- 16 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
The Debug::SetBreakPointForScript() method essentially figures out the SharedFunctionInfo and then duplicates the logic from SetBreakpoint(). Bug: chromium:1162229 Change-Id: Iae98ab5d182739d44e0277b799509723d950f381 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697351 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72782}
-