- 13 Aug, 2020 1 commit
-
-
Kim-Anh Tran authored
This extends the skip list feature from step over to step into. On a step into we can pass a skipList, which contains locations that we do not want to stop at. Bug: chromium:1105765 Change-Id: I70a4ded3f6a7eada14f54ae9c2f994c155c7305b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345224Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#69376}
-
- 11 Aug, 2020 1 commit
-
-
Kim-Anh Tran authored
This change adds support for skipping locations that are in a skipList on step over. This feature is useful for when we are debugging C++ applications that have DWARF information we only want to stop on every breakable location in C++, not non every breakable location on wasm level. Bug: chromium:1105765 Change-Id: Ie835b011a00cf31e0c5b2df1ac96ebd89f53d23a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339458Reviewed-by: Eric Leese <leese@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#69329}
-
- 05 Aug, 2020 1 commit
-
-
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: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 28 Jul, 2020 2 commits
-
-
Leszek Swirski authored
If we're close to a stack overflow when starting a script compile, we may get into a state where main-thread compilation would stack overflow, but background-thread compilation wouldn't. This triggers a failure of a CHECK under --stress-background-compile, but isn't actually an interesting failure. So, we loosen this CHECK to allow the main-thread having a stack overflow (strictly speaking, a RangeError) to count as a "success" for the purposes of comparing against a background compilation success. Bug: v8:10757 Change-Id: I7d687b52d178973b421c42ca0d89b4da0357232a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320649 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69092}
-
Camillo Bruni authored
Isolate::PromiseHasUserDefinedRejectionHandler no longer descends recursively the outer_promise chain but uses an std::stack to avoid stack overflows with very long promise chains. Change-Id: Icdf86a34d89b734adc7139357b2ba6b37a7882ad Bug: chromium:1096139 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316298Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#69090}
-
- 06 Jul, 2020 1 commit
-
-
Leszek Swirski authored
This will allow it to take an OffThreadIsolate in the future, without requiring GetIsolate on SharedFunctionInfo. Change-Id: I7db56d5f0587585f829b26e60683c133760d8ff1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282534Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68696}
-
- 22 Jun, 2020 1 commit
-
-
Dan Elphick authored
This changes black/white list to block/allow list. Bug: v8:10619 Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68464}
-
- 02 Jun, 2020 1 commit
-
-
Clemens Backes authored
This adds support for multiple isolates sharing the same module but setting different breakpoints. This is simulated by having a debugger test that runs in the "--isolates" variant, i.e. two isolates running the same test at the same time. Both isolates will set and remove breakpoints. The DebugInfo will keep a separate list of breakpoints per isolate, and when recompiling a function for debugging it will respect all breakpoints in all isolates. In order to ensure consistency if multiple isolates are setting or removing breakpoints simultaneously, we go back to a more coarse-grained locking scheme, where the DebugInfo lock is held while re-compiling Liftoff functions. While recompilation will install the code in the module-global code table and jump table (and hence all isolates will use it for future calls), only the stack of the requesting isolate is rewritten to immediately use new code. This is OK, because other isolates are not interested in the new breakpoint(s) anyway. On {SetBreakpoint}, we always need to rewrite the stack of the requesting isolate though, even if the breakpoint was set before by another isolate. Drive-by: Some fixes in SharedFunctionInfo in order to support setting breakpoints via the Debug mirror. R=thibaudm@chromium.org Bug: v8:10359 Change-Id: If659afb273260fc5e8124b4b617fb4322de473c7 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218059Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68096}
-
- 11 May, 2020 1 commit
-
-
Clemens Backes authored
Also, rename the WASM_COMPILED frame type to just WASM. R=jkummerow@chromium.org Bug: v8:10389 Change-Id: I71f16f41a69f8b0295ba34bd7d7fad71729546f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187613 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67698}
-
- 07 May, 2020 1 commit
-
-
Clemens Backes authored
Currently WebAssembly breakpoint information survive disabling and re-enabling the debugger. This is different from JavaScript, where they are all removed. The frontend is expected to re-set the breakpoint then. Thus this CL remembers all wasm scripts where breakpoints have been set in the Debug object, and clears them all when the debugger gets disabled. R=bmeurer@chromium.org Bug: v8:10403 Change-Id: I5f8a8f3123727c954921920897ee7bf3b73f0ae8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184969 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#67639}
-
- 28 Apr, 2020 1 commit
-
-
Clemens Backes authored
This CL removes all debugging capabilities from the API provided by WasmDebugInfo: - setting and removing breakpoints - stepping - stack inspection The WasmDebugInfo is still kept, since it's used from tests to instantiate the interpreter. R=thibaudm@chromium.org, bmeurer@chromium.org Bug: v8:10389 Change-Id: I297bfc8df2104dae8b9f9f9b13078026c47698da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164791Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67418}
-
- 20 Apr, 2020 1 commit
-
-
Clemens Backes authored
The flag is on by default, and tests already rely on the new behaviour. This CL removes the flag and immediately affected code. More code will be removed component by component in follow-up CLs. Drive-by: Inline {RemoveBreakpointFromInfo} into {ClearBreakPoint}, which only redirected to that method after this CL. R=thibaudm@chromium.org,bmeurer@chromium.org Bug: v8:10389, v8:10351 Change-Id: I3b18e228dd633cfb25541ddd0f31699b1ceb1db0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154804 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67244}
-
- 30 Mar, 2020 1 commit
-
-
Clemens Backes authored
When stepping in from JS, the stepping frame ID will not be set. Instead of ensuring to set it properly, we can just skip the check for the frame ID. It was needed before, when we didn't properly reset stepping information. Now, it's redundant anyway. Also, ensure that we don't redirect to the interpreter if the --debug-in-liftoff flag is set. Drive-by: Fix and clang-format some parts of the test (no semantic change). R=thibaudm@chromium.org, szuend@chromium.org Bug: v8:10351 Change-Id: I58a3cd68937006c2d6b755a4465e793abcf8a20c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124317Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66904}
-
- 19 Mar, 2020 1 commit
-
-
Clemens Backes authored
Update the "hook on function call" flag also in the wasm case, and slightly change the {IsStepping} logic to stop in any frame if the last step action was anything other than StepNext. In future CLs, this has to be extended further for StepOut and for StepOver at a return location. When that is done, we can also reenable more stepping in the test. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: Ib3aa8c2c2e137690140e5879a33e2bcc340821e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108035 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#66789}
-
- 17 Mar, 2020 1 commit
-
-
Thibaud Michaud authored
And fix a few issues revealed by this new test. Incidentally, the test uses removeBreakpoint which was still untested with Liftoff. But as expected this seems to work out of the box. R=clemensb@chromium.org Bug: v8:10321 Change-Id: Ifa4e867737d925ea8c6c9731575a32f3da3e16dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106206 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66752}
-
- 13 Mar, 2020 1 commit
-
-
Thibaud Michaud authored
Flood functions with breakpoints to prepare them for stepping. With a small modification to the runtime function, this already implements a basic step over functionality. We still cannot resume, step in or step out (including stepping over a return instruction). R=clemensb@chromium.org Bug: v8:10321 Change-Id: Ia4a6335d24c1a511c2f1fc9b48d728f327b3df56 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098732Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#66697}
-
- 11 Feb, 2020 1 commit
-
-
Leszek Swirski authored
Adds support for off-thread allocation to Script allocation and line-end calculation. This includes adding support for keeping/merging a script list on the OffThreadIsolate, and adding syntactical support for logging (in the future this could do actual logging). Bug: chromium:1011762 Change-Id: Id90f2ad7458e90e06f6926f1fce7ef7a1ef50b3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046884Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66213}
-
- 03 Feb, 2020 1 commit
-
-
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: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#66084}
-
- 21 Jan, 2020 1 commit
-
-
Dan Elphick authored
Force source position collection when using --print-break-location. Bug: v8:10132 Change-Id: I4706d9f1e09c52ca7bfb2410485bc3ef26c2128a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011821 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#65885}
-
- 16 Jan, 2020 1 commit
-
-
Z Nguyen-Huu authored
Re-use set breakpoint logic for wasm script to set breakpoint to first breakable position of given wasm function. Bug: v8:9724 Change-Id: Ibd6b59d5b93c6895f71f0114291bf78db03aee0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2001564 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65827}
-
- 18 Dec, 2019 1 commit
-
-
Z Nguyen-Huu authored
In setting breakpoint in wasm, we can find wasm script from location but in removing a breakpoint, only breakpoint id is provided. For wasm, we have a list of all BreakPointInfo objects attached to the Script. From breakpoint id, we iterates all scripts to find the targeted breakpoint and remove it. Bug: chromium:837572 Change-Id: Ia5d0fb7d804fb98270b2103232bc10eb5d4f93a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1959749 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65505}
-
- 04 Dec, 2019 1 commit
-
-
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: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65337}
-
- 22 Nov, 2019 1 commit
-
-
Z Nguyen-Huu authored
This scenario is where user is at the end of Wasm execution and do some stepping. Hence, user should be back at Javascript frame. We can detect that stepping as it exits Wasm Interpreter and prepare debugging as a step-out-ish in Javascript. Bug: chromium:823923, chromium:1019606, chromium:1025151 Change-Id: I29022af0d5e5dcf78d87e83193f6e16fec954e87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1912985 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65122}
-
- 18 Nov, 2019 1 commit
-
-
Z Nguyen-Huu authored
We detect a stepping in Wasm from Javascript into Wasm then prepare the target function for debugging. The trick is redirect the target to interpreter and set a 'fake' breakpoint in the first instruction. Currently we don't need to clear this 'fake' breakpoint since it won't notify unless user intend to step in. Change-Id: Ibe1f9ba31dc6c7919895d3fe31967e9c4699ef63 Bug: chromium:1019606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1902259 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65020}
-
- 15 Nov, 2019 1 commit
-
-
Maya Lekova authored
This helps reduce the number of false positives encountered by the dead variable analysis in gcmole. TBR=jgruber@chromium.org, verwaest@chromium.org, yangguo@chromium.org Bug: v8:9810 Change-Id: I1a34ccaab340e6abc37832b4ce1a0cabc56fa438 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917146 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64981}
-
- 30 Oct, 2019 1 commit
-
-
Sigurd Schneider authored
This CL removes a GC invocation which might not be needed anymore. This CL picks up on a previous attempt to remove this invocation: crrev.com/c/928241 Bug: chromium:1005906, chromium:1019613 Change-Id: I487b5bfd51532fe60cd71444b53874f20eecdf16 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883566Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#64651}
-
- 22 Oct, 2019 1 commit
-
-
Jakob Gruber authored
The natives blob was deprecated in V8 7.8. This CL removes all related functionality, including: - Build system support, i.e.: generation of natives_blob.bin and the v8_extra_library_files gn flag. - Related scripts (js2c.py, concatenate-files.py). - Related API functions (SetNativesDataBlob, InitializeExternalStartupData). - Natives bootstrapping logic. - The InternalArray type (previously exposed through natives). - Other natives-exposed builtins. - Inlining of these builtins. - The dedicated 'uncached external one byte string' type. Step 1 landed in https://crrev.com/c/1824944. Step 2 landed in https://crrev.com/c/1835536. Step 3 (this CL) removes these all functionality related to natives support in V8. Bug: v8:7624 Change-Id: Ice6c2662781efe8417231805276476d32bc5a625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844771 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64446}
-
- 16 Oct, 2019 1 commit
-
-
Michael Starzinger authored
R=clemensb@chromium.org BUG=v8:6847,chromium:893069 Change-Id: I5b5ada546e1d0b9d42ea8f7278671bf2b128bef8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862570Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64308}
-
- 11 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
This is for consistency and compiler-enforced type safety. No change in behavior intended. Change-Id: I31467832ba6c63fd5f97df9fee6221559b283d67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852766 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64244}
-
- 10 Oct, 2019 1 commit
-
-
Michael Starzinger authored
This moves the list of {BreakPointInfo} objects from {WasmModuleObject} to the corresponding {Script} object. Breakpoints are expected to affect all modules/instances for a given script, hence the new placement of the list is a preparation to fully support per-script breakpoints. R=clemensb@chromium.org BUG=v8:6847,chromium:893069 Change-Id: Id97058be5ed79cfdba2cecac5733ba161a6021d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852127Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64213}
-
- 09 Oct, 2019 1 commit
-
-
Yang Guo authored
R=bmeurer@chromium.org Change-Id: I45d41d6074cdf117cdef6128f8544e1a882615c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1849513Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64180}
-
- 07 Oct, 2019 1 commit
-
-
Seth Brenith authored
Just mechanical conversion to remove boilerplate code. When .tq and .h files didn't agree on what a field is named, I used the name from the .h file. In a couple of cases the generated accessor became slightly more specific (HeapObject instead of Object), and I had to update the code that uses those accessors accordingly. Change-Id: Ie3af1590e3889887b167c9d045b07860b01f7d15 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776479Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64142}
-
- 26 Sep, 2019 1 commit
-
-
Clemens Backes authored
R=adamk@chromium.org No-Try: true Change-Id: I71824f52802c125dbee51216054575f44d08d534 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825243 Commit-Queue: Clemens Backes [né Hammacher] <clemensb@chromium.org> Auto-Submit: Clemens Backes [né Hammacher] <clemensb@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63983}
-
- 18 Sep, 2019 1 commit
-
-
Benedikt Meurer authored
Disabling the RegExp compilation cache comes with performance implications, and it doesn't seem to be necessary for debugging. Bug: chromium:992277 Change-Id: I24841f4814bcacb18a3968c37490f201c0c1ccac Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg,v8_linux64_gc_stress_custom_snapshot_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1805637 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63876}
-
- 28 Aug, 2019 1 commit
-
-
Yang Guo authored
This partially reverts commit 763f63ff. Reason for the revert is that the breaking at stack overflow does not introduce improvement of usability, but rather exposes many issues caused by the fact that V8 cannot perform a lot of functionality close to the stack limit. We keep the test, slightly modified, and use a better way to detect stack overflow. Bug: chromium:997469 Change-Id: I32bdf96767812b19f138310cc2dbd6a818fbf031 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771792Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63426}
-
- 26 Aug, 2019 1 commit
-
-
Yang Guo authored
R=sigurds@chromium.org Bug: chromium:997469 Change-Id: I83c8a50a5626b3e4679ff7977474d495cdbf7e90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768369 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63399}
-
- 05 Aug, 2019 1 commit
-
-
Simon Zünd authored
This CL changes the way AccessorPairs are collected for instantiation when debug break trampolines are installed. Instead of walking the heap and looking at AccessorPairs directly, we look at all JSObjects and collect AccessorPairs via each objects descriptor array. This way, we can associate the correct native context with each collected AccessorPair. The current native context is not always the correct context to instantiate the getter and setter JSFunctions for an AccessorPair. Bug: chromium:986063 Change-Id: I124a0802f4938b95f1ad75efc65eb05b66bcfc67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735310 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#63071}
-
- 12 Jul, 2019 1 commit
-
-
Peter Marshall authored
Everyone was getting a copy of this through debug.h. Bug: v8:9396 Change-Id: I5189cb4bf27a3381768b0be479d7b3d60dec20bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695472 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62670}
-
- 26 Jun, 2019 1 commit
-
-
Sathya Gunasekaran authored
Change-Id: I8e6f10d6a5cba981134b44fda1a8ae3a4ea0fc97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675959 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62371}
-
- 17 Jun, 2019 1 commit
-
-
Maciej Goszczycki authored
Rename LargeObjectIterator to LargeObjectSpaceObjectIterator. Rename SemiSpaceIterator to SemiSpaceObjectIterator. Rename CombinedHeapIterator to CombinedHeapObjectIterator. Rename ReadOnlyHeapIterator to ReadOnlyHeapObjectIterator. Rename HeapIterator to HeapObjectIterator. Rename HeapObjectIterator to PagedSpaceObjectIterator. Rename PagedSpaces to PagedSpaceIterator. Bug: v8:9183 Change-Id: If4bd65d81e50bb45d207a897baaca8b723e4f10b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645914Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#62217}
-