- 08 Feb, 2021 1 commit
-
-
Clemens Backes authored
For functions with a very large stack, the debug side table repeats a lot of information: Most values will be spilled to the stack, still every single entry in the debug side table repeats information about them (type, stack offset). This leads to the size of the debug side table to be quadratic in the size of the function. In the linked bug, the generation of the debug side table took ~400ms, whereas Liftoff compilation alone just took 16ms. This CL optimized the debug side table by delta-encoding the entries, i.e. only storing stack slots that changed. This reduces the size of the table significantly, at the cost of making lookup slower, since that now has to search the table backwards for the last entry that had information about a specific slot. For now, this seems like a good compromise. If it turns out to be a problem, we could speed up the lookup by either forcing a full dump of the stack state after N entries, or by dynamically inserting new entries during lookup, whenever we find that we had to search backwards more than N entries. That would speed up subsequent lookups then. On the reproducer in the linked bug, this change reduces the time to generate the debug side table from ~400ms to ~120ms. Before this CL, the debug side table has 13,314 entries with a total of 38,599,606 stack value entries. After this CL, it shrinks to 20,037 stack value entries in the 13,314 entries (average of ~1.5 instead of ~2,899). R=thibaudm@chromium.org Bug: chromium:1172299 Change-Id: Ie726bb82d4c6648cc9ebd130115ee7ab3d1d551b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676636Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72558}
-
- 13 Jan, 2021 1 commit
-
-
Benedikt Meurer authored
This moves the logic for the debug name heuristic, which derives names for imported and exported entities from the relevant tables, into wasm-debug.{cc,h} and stores these maps on the DebugInfoImpl rather than on the WasmModule. Drive-by-fix: Also use the import table based heuristic for function names, just like we use it for everything else. Bug: chromium:1164305 Change-Id: I8a21e0880c680079f63e6607b5b62c788049b9e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625870 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72061}
-
- 11 Jan, 2021 1 commit
-
-
Benedikt Meurer authored
Previously the implementation of the scope iterator objects and the debug proxy lived in src/wasm, and they are now being moved to src/debug, to better align with the JavaScript debugging interface, which also lives in src/debug. Bug: chromium:1162229, chromium:1071432 Change-Id: I7f89ced88a1231ad6a923be6e85a93f1876a2024 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621084Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72007}
-
- 08 Jan, 2021 1 commit
-
-
Benedikt Meurer authored
Previously the Debug Proxy API that's exposed on Wasm frames by Runtime.evaluateOnCallFrame() was implemented via actual JSProxy instances. That means that all entities such as "memories", "tables", "stack", "globals", etc. were JSProxy instances with "get" and "has" traps. But that has a couple of down-sides: 1. In DevTools front-end, the proxies are shown as JSProxy, which is not very useful to developers, since they cannot interact with them nor can they inspect their contents. And the object preview also only shows "Proxy {}" for them. 2. The performance doesn't scale well, which becomes a painful bottleneck with larger Wasm modules that contain hundreds of thousands of functions or globals. 3. We cannot use the JSProxy instances in the Scope view (for the reasons outlined in 1.) and hence we have different logic to provide Scope values than values in the rest of DevTools, which led to subtle but annoying bugs and inconsistencies. This also changes the "locals" implementation by querying the values ahead of time, similar to the object exposed to the Scope view, instead of on-demand, since the "locals" object might survive the current debugger pause and peeking into the stack afterwards would read invalid memory (and might even be a security issue). For being able to change locals we need to look into a similar solution as what we have for JavaScript locals already. The expression stack already works this way. For performance reasons (especially scaling to huge, realistic Wasm modules), we cache the per-instance proxies ("functions", "memories", "tables" and "globals") on the WasmInstanceObject and reuse them (which is safe since they have a `null` prototype and are non-extensible), and we also cache the proxy maps (with the interceptors) on the JSGlobalObject per native context. Doc: http://bit.ly/devtools-wasm-entities Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241 Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#71981}
-
- 05 Jan, 2021 1 commit
-
-
Benedikt Meurer authored
Previously the proxies that make up the DebugEvaluate implementation for Wasm frames lived in wasm-js.cc, but that was quite confusing since (a) the rest of the debug support for Wasm lives in wasm-debug.cc (and we intend to eventually unify the DebugEvaluate and Scope objects), and (b) the wasm-js.cc file is explicitly about the WebAssembly JS API that's part of the WebAssembly specification, and the DebugEvaluate proxies aren't part of that. Bug: chromium:1162229, chromium:1071432, chromium:1127914 Change-Id: I63016dcace6d8e2af4a03c8eed4f02d464c1dee1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609418 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71911}
-
- 26 Nov, 2020 1 commit
-
-
Clemens Backes authored
This specific case was not implemented or tested before. Implementing it actually simplifies some of the existing logic, since StepOut can now reuse the generic logic in debug.cc for all cases (Wasm->Wasm, Wasm->JS, JS->Wasm). Drive-by: 1) Fix typo ("skip" -> "step"). 2) Move the check for Liftoff code from debug.cc to wasm-debug.cc, where it fits better. 3) Remove a TODO which is done already. R=thibaudm@chromium.org, szuend@chromium.org Bug: chromium:1145176 Change-Id: I415ca1d8bacef5b21bf1dafd9e16417ec2d12c7c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560719 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#71428}
-
- 25 Nov, 2020 1 commit
-
-
Clemens Backes authored
This is a minor refactoring before fixing actual issues. 1) The update of the {per_isolate_data_} is moved into {FloodWithBreakpoints}, which is already taking the mutex. 2) The {PrepareStep} method takes a {WasmFrame*} directly instead of its ID. In most cases, this prevents the creation of an additional stack frame iterator. R=thibaudm@chromium.org Bug: chromium:1145176 Change-Id: I1a6cd15550bbb4ef78ba522427bed1c23185569e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2558318Reviewed-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@{#71399}
-
- 05 Oct, 2020 1 commit
-
-
Philip Pfaffe authored
When debugging WebAssembly, calls to evaluateOnCallFrame always return undefined. This CL enables evaluateOnCallFrame for WebAssembly and creates a proxy object that is injected into the evaluation context. Bug: chromium:1127914 Change-Id: I3f5cff3be2c9de45c7b1f3f7ed4fc2e1cc545ac6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429265 Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#70315}
-
- 28 May, 2020 1 commit
-
-
Clemens Backes authored
Instead of keeping a single {stepping_frame_} per native module, we now keep one frame id per isolate. Hence, each isolate can step through a different frame, independent of other isolates. The on-stack-replacement of the stepping frame already works on a per-isolate basis, since we only replace the return address of a single frame, part of the isolate that requested stepping. The new test (which also executes in a variant with two concurrent isolates) revealed some more data races to fix. R=thibaudm@chromium.org Bug: v8:10359 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Change-Id: I0bb013737162bd09b9f4be9c08990bca7bf736ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214838Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68045}
-
- 26 May, 2020 1 commit
-
-
Clemens Backes authored
The Isolate is only used to access the wasm engine, and the accounting allocating. The latter is also linked directly from the wasm engine, and the engine is linked from the native module, to which the DebugInfoImpl already has access. Hence, this CL removes the redundant Isolate pointers, and just accesses the engine and the allocator via the NativeModule. R=thibaudm@chromium.org Change-Id: Ib51cee2d166443a34e22fa02e8ad1549328aaa7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214827Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67966}
-
- 18 May, 2020 1 commit
-
-
Clemens Backes authored
For debugging (either with --print-wasm-code, or inspecting the current code object in a debugger) it's helpful to also see the debug side table, if available. This CL adds print support for that, and uses it when printing wasm code, and after generating a new debug side table. R=thibaudm@chromium.org Bug: v8:10359 Change-Id: I700b6eacb80f015212115e91b94c513e88c04288 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202902 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67848}
-
- 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}
-
- 24 Apr, 2020 1 commit
-
-
Clemens Backes authored
The cctests for breakpoints were still executing in the interpreter. This CL moves them over to Liftoff. Note that the additional methods on {DebugInfo} will be reused for other purposes, see https://crrev.com/c/1941139. R=jkummerow@chromium.org Bug: v8:10389 Change-Id: Ia88150612377d6e7db0514af1efe091124b3ddce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162852Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67360}
-
- 16 Apr, 2020 1 commit
-
-
Philip Pfaffe authored
This CL relands the implementation of the __getLocal and __sbrk APIs of the evaluator interface reverted in efea7407. Update the original commit to account for a changes to the import function name tracking and defaulting to debugging with liftoff. Change-Id: I9674aad419fb1dab0a9ecbb5d3fd4c33186b127a Bug: chromium:1020120 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151353 Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67178}
-
- 15 Apr, 2020 1 commit
-
-
Kim-Anh Tran authored
Bug: chromium:1043034 Change-Id: I18b1c307ab198e7fbd4d5bc7df399c310f317c4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149419Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#67159}
-
- 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}
-
- 26 Mar, 2020 1 commit
-
-
Kim-Anh Tran authored
This change adds a stack scope for wasm debugging. Currently the local scope contains both local variables as well as the expression stack. For now, this change duplicates the information available on stacks into the stack scope, until we have added support for the stack scope in the DevTools front-end. Bug: chromium:1043034 Change-Id: Ib0a07e07be7c53003526a7b1e1dbfaa1116b41ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093510 Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66867}
-
- 23 Mar, 2020 1 commit
-
-
Thibaud Michaud authored
Remove unused breakpoints as we hit them. OSR in this case does not work properly yet, because we are missing the source position for the removed breakpoint in the new code. R=clemensb@chromium.org Bug: v8:10321 Change-Id: I908546c1b37ca044166b24b4900126ab79f117ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111216 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66821}
-
- 16 Mar, 2020 1 commit
-
-
Clemens Backes authored
This implements inspection of live registers on breakpoints in Liftoff. To that end, the frame pointer of the WasmDebugBreak frame is remembered when iterating the stack. Based on a platform-specific implementation of {WasmDebugBreakFrameConstants}, the offset of the respective register within that frame is computed, and the value is read from the frame. As a drive-by, the wasm debug side table is storing register codes as liftoff codes, which can also store register pairs (needed for i64 on 32-bit platforms, and for SIMD, which is not supported yet). R=jkummerow@chromium.org CC=thibaudm@chromium.org Bug: v8:10222 Change-Id: I01b669baf56430e100cd46cc46f210121ea679da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66719}
-
- 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}
-
- 24 Feb, 2020 1 commit
-
-
Clemens Backes authored
This extends the debug side table to also store register locations in addition to constants and stack values. Previously, every value that was not constant was assumed to be spilled to the stack. This made sense, because without breakpoints we would only emit debug side table entries at call sites, where all registers are spilled. With breakpoints, this changes. At break locations, values might be live in registers. The logic to decide whether a value will live in the register or on the stack is extended, because we sometimes generate the debug side table entry at a point where the registers are not spilled yet. The debug side table entry creation needs to account for that, and assume that these registers will still be spilled. R=thibaudm@chromium.org Bug: v8:10147, v8:10222 Change-Id: I3b020dfaa29fc007047663706ee286180a996bfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066960 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#66407}
-
- 20 Feb, 2020 1 commit
-
-
Clemens Backes authored
This refactors the debug side table such that we can easily add register information later. In particular - vectors for types and stack offsets are combined into one; - constants are stored in the same vector; - locals and operand stack values are stored in the same vector. A follow-up CL will extend the DebugSideTable to also encode locals or operand stack values held in registers. R=thibaudm@chromium.org Bug: v8:10147, v8:10222 Change-Id: I97adb56b31afdb22896530c7ba2e8a24b5d31da9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062405 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#66374}
-
- 19 Feb, 2020 1 commit
-
-
Thibaud Michaud authored
After compiling a function with a different set of breakpoints, update return addresses on the stack so that execution resumes in the new code. This allows new breakpoints to take effect immediately, which is the expected behavior and a prerequisite for stepping. R=clemensb@chromium.org Bug: v8:10147 Change-Id: I67eb3b4ce23a1f3b0519935447f8b847ec888ead Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064218Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#66351}
-
- 04 Feb, 2020 1 commit
-
-
Clemens Backes authored
The debug side table is indexed by pc offset. Offsets change if breakpoints are added or removed, hence we cannot reuse the debug side table when compiling another version of the function (with a different set of breakpoints). Thus store the debug side table per code object instead of per function. R=thibaudm@chromium.org Bug: v8:10147 Change-Id: Ifd77dd8f43c9b80bc4715ffe5ca8f0adca2aaf42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030922Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66110}
-
- 22 Jan, 2020 1 commit
-
-
Clemens Backes authored
This CL adds a --debug-in-liftoff flag, which takes another path in {WasmScript::SetBreakPointForFunction}, and sets the breakpoint via {wasm::DebugInfo} (Liftoff-related) instead of {WasmDebugInfo} (C++ interpreter related). Actual breakpoint support is not there yet, so the new test which sets this flag does not currently break anywhere. This will change with a future CL. R=thibaudm@chromium.org Bug: v8:10147 Change-Id: I95a905e666b8f502366d2c7273c8f25a267ee184 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2012920 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#65921}
-
- 16 Jan, 2020 1 commit
-
-
Clemens Backes authored
We were decoding the names of locals into a C++ data structure, and then generated a FixedArray out of that, stored in the on-heap WasmDebugInfo. In order to support name lookup for debugging with Liftoff, where no WasmDebugInfo will be present, this CL refactors the C++ data structure to allow direct lookups and stores it in the C++ DebugInfo structure. With this CL, the names are still only used from the old interpreter-based debugging path. A follow-up CL will then also use it from Liftoff. R=thibaudm@chromium.org Bug: v8:10019 Change-Id: I1397021b5d69b9346fc26f5e83653360f428c5e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002541 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#65819}
-
- 15 Jan, 2020 1 commit
-
-
Clemens Backes authored
This extends the debug side table to track stack offsets of locals and operand stack slots, and uses this to read spilled value from the physical stack frame when inspecting Liftoff frames. R=jkummerow@chromium.org Bug: v8:10019 Change-Id: Ida7ab5256fcc1e9d408201f4eafe26919f1432a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000739 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65789}
-
- 09 Jan, 2020 1 commit
-
-
Clemens Backes authored
Store the types of locals in the {DebugSideTable}, and the type of all stack values on each entry. Especially the stack value types would be difficult to reconstruct later on. R=jkummerow@chromium.org Bug: v8:10019 Change-Id: I9b945b4e0a51166460420099908442703d3d486a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1975759 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65670}
-
- 27 Dec, 2019 1 commit
-
-
Clemens Backes authored
This adds a {wasm::DebugInfo} struct which will hold the {wasm::DebugSideTable}s for individual Liftoff functions, and will use them to construct local scope information. R=jkummerow@chromium.org, bmeurer@chromium.org Bug: v8:10019 Change-Id: I7869cec5000e9b126c891a242fcccfc53c67662e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1975758 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65563}
-
- 17 Dec, 2019 1 commit
-
-
Clemens Backes authored
For out-of-line code, we need to generate the debug side table information at the point where the out-of-line code is being triggered, not when it is emitted (at the end of the function). This CL also adds more tests to check the actual content of the debug side table in different scenarios. R=jkummerow@chromium.org Bug: v8:10019 Change-Id: I7714c86ee7edc4918b5ecc97cbded84c27b00e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967388Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65481}
-
- 06 Dec, 2019 1 commit
-
-
Clemens Backes authored
This adds a method to generate the debug side table via Liftoff, and adds first tests that check that the number of entries is as expected. These tests will be extended in a follow-up CL to test the actual content of the debug side table. R=mstarzinger@chromium.org Bug: v8:10019 Change-Id: I393ffabed3408463ffba232a66e2dffd7dd74f15 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954390 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65370}
-
- 26 Nov, 2019 1 commit
-
-
Clemens Backes authored
This adds the data structure and a builder for it, without ever using it yet. Users and tests will be added in a follow-up CL. R=mstarzinger@chromium.org Bug: v8:10019 Change-Id: I5c332c8b3a499d3844113fbd4108a9138eef01f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932365 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65165}
-
- 24 Oct, 2019 1 commit
-
-
Clemens Backes authored
This method should be reused for compiled frames, hence this CL moves it to the top-level in wasm-debug.cc, and makes it externally available via wasm-debug.h. R=mstarzinger@chromium.org Bug: v8:9676 Change-Id: If2fbcad1d0911efe4c2169e8a5bd85b598ac335f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876060Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64538}
-
- 11 Nov, 2016 1 commit
-
-
titzer authored
This CL moves all heap-allocated WASM data structures, both ones that are bonafide JSObjects and ones that are FixedArrays only, into a consistent place with consistent layout. Note that not all accessors are complete, and I haven't fully spread the new static typing goodness to all places in the code. R=ahaas@chromium.org,rossberg@chromium.org CC=gdeepti@chromium.org,mtrofin@chromium.org,clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2490663002 Cr-Commit-Position: refs/heads/master@{#40913}
-
- 19 Oct, 2016 1 commit
-
-
titzer authored
R=clemensh@chromium.org,ahaas@chromium.org BUG= Review-Url: https://chromiumcodereview.appspot.com/2428343005 Cr-Commit-Position: refs/heads/master@{#40426}
-
- 12 Oct, 2016 1 commit
-
-
clemensh authored
For the asm.js to WASM pipeline, the current stack traces only show low-level WASM information. This CL maps this back to asm.js source positions. It does so by attaching the asm.js source Script to the compiled WASM module, and emitting a delta-encoded table which maps from WASM byte offsets to positions within that Script. As asm.js code does not throw exceptions, we only store a mapping for call instructions. The new AsmJsWasmStackFrame implementation inherits from WasmStackFrame, but contains the logic to provide the source script and the position inside of it. What is still missing is the JSFunction object returned by CallSite.getFunction(). We currently return null. R=jgruber@chromium.org, titzer@chromium.org BUG=v8:4203 Review-Url: https://codereview.chromium.org/2404253002 Cr-Commit-Position: refs/heads/master@{#40205}
-
- 29 Jun, 2016 1 commit
-
-
titzer authored
This changes many interfaces to accept StandardFrames instead of JavaScriptFrames, and use the StackTraceFrameIterator instead of the JavaScriptFrameIterator. Also, the detailed frame information array now contains the script in addition to the function, as wasm frames are not associated to any javascript function. This is a rebase of (https://codereview.chromium.org/2069823003/), since clemensh's internship has ended. R=yangguo@chromium.org,ahaas@chromium.org BUG= Review-Url: https://codereview.chromium.org/2109093003 Cr-Commit-Position: refs/heads/master@{#37379}
-
- 20 Jun, 2016 1 commit
-
-
clemensh authored
All function which potentially do heap allocations now take a Handle on a WasmDebugInfo. This unfortunately requires to make some function static, since otherwise the "this" pointer would not be handlified. R=ahaas@chromium.org, titzer@chromium.org BUG=chromium:613110 Review-Url: https://codereview.chromium.org/2074933005 Cr-Commit-Position: refs/heads/master@{#37099}
-
- 17 Jun, 2016 1 commit
-
-
clemensh authored
All debugging-related information is now stored inside a dedicated object, which is only allocated if debugging support is needed. This is also where later a reference to the interpreter will be stored for executing to-be-debugged functions and providing stack inspection. R=titzer@chromium.org, ahaas@chromium.org BUG=chromium:613110 Review-Url: https://codereview.chromium.org/2050953003 Cr-Commit-Position: refs/heads/master@{#37055}
-