- 08 Apr, 2020 1 commit
-
-
Clemens Backes authored
This is a reland of 44826509. TSan issue were fixed in https://crrev.com/c/2139574. One test failing in the 'stress' variant is skipped for now, until we figure out what the intended behaviour actually is. Original change's description: > [wasm] Debug in Liftoff by default > > This flips the --debug-in-liftoff flag to be on by default. > There are still some outstanding issues with that configuration, but not > more than with the interpreter configuration. Thus flip now, such that > we can fully focus on stabilizing that config. > > R=ecmziegler@chromium.org > > Bug: v8:10351 > Change-Id: I7681f40aa2516557ef3ab4efd9a2c1f88e3b4df7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135727 > Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67018} Bug: v8:10351, v8:10403 Change-Id: I4c2f1af46233546d6ebeb638c7ef10aac56cd92d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139575 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/master@{#67049}
-
- 06 Apr, 2020 2 commits
-
-
Zhi An Ng authored
This reverts commit 44826509. Reason for revert: Broke V8 Linux64 TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/30932? Original change's description: > [wasm] Debug in Liftoff by default > > This flips the --debug-in-liftoff flag to be on by default. > There are still some outstanding issues with that configuration, but not > more than with the interpreter configuration. Thus flip now, such that > we can fully focus on stabilizing that config. > > R=ecmziegler@chromium.org > > Bug: v8:10351 > Change-Id: I7681f40aa2516557ef3ab4efd9a2c1f88e3b4df7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135727 > Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67018} TBR=clemensb@chromium.org,ecmziegler@chromium.org Change-Id: Idd0f7f6101e55785fba9afc3d9af09c0324d7c3b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10351 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137565Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67019}
-
Clemens Backes authored
This flips the --debug-in-liftoff flag to be on by default. There are still some outstanding issues with that configuration, but not more than with the interpreter configuration. Thus flip now, such that we can fully focus on stabilizing that config. R=ecmziegler@chromium.org Bug: v8:10351 Change-Id: I7681f40aa2516557ef3ab4efd9a2c1f88e3b4df7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135727Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67018}
-
- 26 Mar, 2020 1 commit
-
-
Clemens Backes authored
We were sometimes stopping on a one-shot breakpoints in JS code even though the last user action was actually a resume. This CL fixes that clearing all stepping in JS whenever we hit a breakpoint in wasm. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: Ie5d12bb0c9e766bcbd5ad0aa225a8b14b4d608b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120588Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66869}
-
- 25 Mar, 2020 3 commits
-
-
Clemens Backes authored
Using the "logSourceLocation" function from protocol-test.js prints slightly better location information for wasm, and especially much better information for JS breakpoints. This helps understanding and debugging these tests. R=thibaudm@chromium.org Bug: v8:10351 Change-Id: I51c7d168d2cb19fb8469b4a2eb372c2b95650fcb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120539Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66863}
-
Thibaud Michaud authored
R=clemensb@chromium.org Bug: v8:10321 Change-Id: I318d46fa638c1d6f4d5d347e5aa0ad1faf02d5e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120532 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66855}
-
Clemens Backes authored
A StepOver at a return (either explicit return instruction, or implicit return at the end of the function) should stop again in the caller frame. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: I313e6b612ac52e73b33ef07c6da1ced2aa0db600 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110250Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66852}
-
- 24 Mar, 2020 1 commit
-
-
Clemens Backes authored
This fixes issues with replacing the return address of deeper (non-top) wasm frames, i.e. frames which are at a call position. The replaced address should also point after the call in the new code, so we don't execute the same call again. This is achieved by using slightly different encodings for breakpoint positions and other (wasm instruction) positions. Breakpoints set {is_instruction} to {false} in the source position table entry, whereas usual wasm instruction set it to {true}. Also, during stack walking for OSR, we remember whether we want to OSR to the position before the instruction (if it's the top frame), or after the call instruction (if it's deeper in the stack). We then use the {is_instruction} predicate to find the right location. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: I73212a7532c6ecf4c82bde76fe4059c8203e422c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116206Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66850}
-
- 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 2 commits
-
-
Thibaud Michaud authored
R=clemensb@chromium.org Bug: v8:10321 Change-Id: Ia082b842de8947ead3931943b3bc05903a0f9e29 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101002Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#66704}
-
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}
-
- 09 Jan, 2020 1 commit
-
-
Eric Leese authored
Inspector will no longer report per-function wasm scripts or provide wasm disassembly. Locations in wasm are now consistently reported through the inspector API as lineNumber=0 columnNumber=byte offset in module. Bug: chromium:1013527, chromium:1003022 Change-Id: Ide85bbaa85ad75f29248ff82a3e7f3e40688d377 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991481 Commit-Queue: Eric Leese <leese@chromium.org> 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@{#65660}
-
- 21 Nov, 2019 1 commit
-
-
Clemens Backes authored
This is an unmodified reland of 3c98a2a3. The actual issue was fixed in https://crrev.com/c/1926769. Original change's description: > [wasm] Prevent breakpoints on nonbreakable positions > > If a breakpoint is set on a non-breakable position, the wasm interpreter > just stores the value 0xFF (kInternalBreakpoint) in the function body > (actually, a copy of the function body). This might overwrite immediates > and cause subsequent failures in the wasm interpreter. > > In JavaScript, breakpoints are just forwarded to the next breakable > position. This CL implements the same for WebAssembly. > A cctest tests this behavior, and the existing > wasm-stepping-byte-offsets.js inspector test is extended to also set the > breakpoint within an i32 constant immediate. > > R=leese@chromium.org, mstarzinger@chromium.org > CC=bmeurer@chromium.org > > Bug: chromium:1025184 > Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65070} Bug: chromium:1025184 Change-Id: I5e16df645bbacf039b7a5e55a0c2a64cdb4c6a32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926152 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65093}
-
- 20 Nov, 2019 2 commits
-
-
Clemens Backes authored
This reverts commit 3c98a2a3. Reason for revert: Fails on arm: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12134 Original change's description: > [wasm] Prevent breakpoints on nonbreakable positions > > If a breakpoint is set on a non-breakable position, the wasm interpreter > just stores the value 0xFF (kInternalBreakpoint) in the function body > (actually, a copy of the function body). This might overwrite immediates > and cause subsequent failures in the wasm interpreter. > > In JavaScript, breakpoints are just forwarded to the next breakable > position. This CL implements the same for WebAssembly. > A cctest tests this behavior, and the existing > wasm-stepping-byte-offsets.js inspector test is extended to also set the > breakpoint within an i32 constant immediate. > > R=leese@chromium.org, mstarzinger@chromium.org > CC=bmeurer@chromium.org > > Bug: chromium:1025184 > Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65070} TBR=mstarzinger@chromium.org,clemensb@chromium.org,bmeurer@chromium.org,leese@chromium.org Change-Id: I7468ea3b15fecccdea521308325cf4851e0a0396 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1025184 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926032Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65074}
-
Clemens Backes authored
If a breakpoint is set on a non-breakable position, the wasm interpreter just stores the value 0xFF (kInternalBreakpoint) in the function body (actually, a copy of the function body). This might overwrite immediates and cause subsequent failures in the wasm interpreter. In JavaScript, breakpoints are just forwarded to the next breakable position. This CL implements the same for WebAssembly. A cctest tests this behavior, and the existing wasm-stepping-byte-offsets.js inspector test is extended to also set the breakpoint within an i32 constant immediate. R=leese@chromium.org, mstarzinger@chromium.org CC=bmeurer@chromium.org Bug: chromium:1025184 Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65070}
-
- 15 Nov, 2019 1 commit
-
-
Eric Leese authored
Currently the inspector reports Wasm in one of two ways: - If there is a source map, report one script per Wasm script, with bytecode but no source. - If there is no source map, report one script per Wasm function, with source (Wasm disassembly) but no bytecode. With this change, behavior with source map is same, but without source map it will report both ways. This will allow us to change the frontend to do its own disassembly, allowing us to remove the per-function scripts in a future change. Bug: chromium:1013527 Change-Id: I0c559ad08896e8d0da419e3c6ad8d1edff3976fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899782Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Eric Leese <leese@chromium.org> Cr-Commit-Position: refs/heads/master@{#64980}
-
- 08 Oct, 2019 1 commit
-
-
Clemens Backes authored
This brings our constants back in line with the changed spec text. We already use kExprTableGet and kExprTableSet, but for locals and globals we still use the old wording. This renaming is mostly mechanical. PS1 was created using: ag -l 'kExpr(Get|Set|Tee)Local' src test | \ xargs -L1 sed -E 's/kExpr(Get|Set|Tee)Local\b/kExprLocal\1/g' -i PS2 contains manual fixes. R=mstarzinger@chromium.org Bug: v8:9810 Change-Id: I1617f1b2a100685a3bf56218e76845a9481959c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847354Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64161}
-
- 30 Jan, 2019 1 commit
-
-
Sven Sauleau authored
We noticed that almost every call site were loading both files, the split isn't necessary anymore. In some message tests, removed the absolute line number to allow future changes. Bug: v8:8726 Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545 Reviewed-on: https://chromium-review.googlesource.com/c/1446452 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#59220}
-
- 13 Sep, 2018 1 commit
-
-
Aseem Garg authored
This CL enables source maps support for wasm. Devtools should be able to pick up source_mapping_url parsed here and load the corresponding source maps. R=kozyatinskiy@chromium.org,clemensh@chromium.org,titzer@chromium.org,yangguo@chromium.org BUG=v8:8081 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I1db0ff597d229e7db8d383fe9ee081c7fa4e7648 Reviewed-on: https://chromium-review.googlesource.com/1185973 Commit-Queue: Aseem Garg <aseemgarg@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55878}
-