AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
aee1e1fb8d
v8/test/inspector/debugger/asm-js-breakpoint-before-exec-expected.txt

96 lines
5.5 KiB
Plaintext
Raw Normal View History

Fix detection of BUILTIN functions In the asm.js to wasm pipeline, we generate an entry function with BUILTIN code, but still attached to a TYPE_NORMAL script. This fix avoids trying to set a breakpoint there, resulting in a crash on DCHECK(shared->HasDebugInfo()). Also add two inspector tests to track regressions. BUG=v8:5568 R=titzer@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2457433002 Cr-Commit-Position: refs/heads/master@{#40633}
2016-10-28 06:47:58 +00:00
This test runs asm.js which calls back to JS. Before executing (after the script is parsed) we set breakpoints in the asm.js code.
Running test: enableDebugger
Running test: addScript
Script nr 1 parsed!
First script; assuming testFunction.
[asm.js] [inspector-test] Avoid breakpoint on "use asm" statement Ignition does not emit any byte code for some literal expression statements, so avoid testing for it. R=rmcilroy@chromium.org BUG=v8:5757 Review-Url: https://codereview.chromium.org/2612013002 Cr-Commit-Position: refs/heads/master@{#42067}
2017-01-04 13:29:35 +00:00
Flooding script with breakpoints for the lines 3 to 20...
Fix detection of BUILTIN functions In the asm.js to wasm pipeline, we generate an entry function with BUILTIN code, but still attached to a TYPE_NORMAL script. This fix avoids trying to set a breakpoint there, resulting in a crash on DCHECK(shared->HasDebugInfo()). Also add two inspector tests to track regressions. BUG=v8:5568 R=titzer@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2457433002 Cr-Commit-Position: refs/heads/master@{#40633}
2016-10-28 06:47:58 +00:00
Setting breakpoint on line 3
error: undefined
Setting breakpoint on line 4
error: undefined
Setting breakpoint on line 5
error: undefined
Setting breakpoint on line 6
error: undefined
Setting breakpoint on line 7
error: undefined
Setting breakpoint on line 8
error: undefined
Setting breakpoint on line 9
error: undefined
Setting breakpoint on line 10
error: undefined
Setting breakpoint on line 11
error: undefined
Setting breakpoint on line 12
error: undefined
Setting breakpoint on line 13
error: undefined
Setting breakpoint on line 14
error: undefined
Setting breakpoint on line 15
error: undefined
Setting breakpoint on line 16
error: undefined
Setting breakpoint on line 17
error: undefined
Setting breakpoint on line 18
error: undefined
Setting breakpoint on line 19
error: undefined
Running test: runTestFunction
Script nr 2 parsed!
Paused #1
- [0] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":17,"columnNumber":2}
- [1] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
Paused #2
- [0] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":18,"columnNumber":12}
- [1] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
Paused #3
[ignition] removed nop bytecode Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them. There are at least two changes which this CL produce: - we don't provide break position when we load local variable (still provide when load variable from global), - we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement. More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing Bug: v8:6425 Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda Reviewed-on: https://chromium-review.googlesource.com/543161 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46742}
2017-07-17 19:02:35 +00:00
- [0] {"functionName":"generateAsmJs","function_lineNumber":1,"function_columnNumber":24,"lineNumber":3,"columnNumber":31}
[debugger] do not use asm validator for debug code. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2492713005 Cr-Commit-Position: refs/heads/master@{#40934}
2016-11-11 15:12:46 +00:00
- [1] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":18,"columnNumber":12}
- [2] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
[asm.js] [inspector-test] Avoid breakpoint on "use asm" statement Ignition does not emit any byte code for some literal expression statements, so avoid testing for it. R=rmcilroy@chromium.org BUG=v8:5757 Review-Url: https://codereview.chromium.org/2612013002 Cr-Commit-Position: refs/heads/master@{#42067}
2017-01-04 13:29:35 +00:00
Paused #4
[debugger] do not use asm validator for debug code. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2492713005 Cr-Commit-Position: refs/heads/master@{#40934}
2016-11-11 15:12:46 +00:00
- [0] {"functionName":"generateAsmJs","function_lineNumber":1,"function_columnNumber":24,"lineNumber":10,"columnNumber":4}
- [1] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":18,"columnNumber":12}
- [2] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
[asm.js] [inspector-test] Avoid breakpoint on "use asm" statement Ignition does not emit any byte code for some literal expression statements, so avoid testing for it. R=rmcilroy@chromium.org BUG=v8:5757 Review-Url: https://codereview.chromium.org/2612013002 Cr-Commit-Position: refs/heads/master@{#42067}
2017-01-04 13:29:35 +00:00
Paused #5
Fix detection of BUILTIN functions In the asm.js to wasm pipeline, we generate an entry function with BUILTIN code, but still attached to a TYPE_NORMAL script. This fix avoids trying to set a breakpoint there, resulting in a crash on DCHECK(shared->HasDebugInfo()). Also add two inspector tests to track regressions. BUG=v8:5568 R=titzer@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2457433002 Cr-Commit-Position: refs/heads/master@{#40633}
2016-10-28 06:47:58 +00:00
- [0] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":19,"columnNumber":2}
- [1] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
Paused #6
[debugger] do not use asm validator for debug code. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2492713005 Cr-Commit-Position: refs/heads/master@{#40934}
2016-11-11 15:12:46 +00:00
- [0] {"functionName":"redirectFun","function_lineNumber":7,"function_columnNumber":24,"lineNumber":8,"columnNumber":6}
- [1] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":19,"columnNumber":2}
- [2] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
Paused #7
[debugger] do not use asm validator for debug code. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2492713005 Cr-Commit-Position: refs/heads/master@{#40934}
2016-11-11 15:12:46 +00:00
- [0] {"functionName":"callDebugger","function_lineNumber":4,"function_columnNumber":25,"lineNumber":5,"columnNumber":6}
- [1] {"functionName":"redirectFun","function_lineNumber":7,"function_columnNumber":24,"lineNumber":8,"columnNumber":6}
- [2] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":19,"columnNumber":2}
- [3] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
Paused #8
Fix detection of BUILTIN functions In the asm.js to wasm pipeline, we generate an entry function with BUILTIN code, but still attached to a TYPE_NORMAL script. This fix avoids trying to set a breakpoint there, resulting in a crash on DCHECK(shared->HasDebugInfo()). Also add two inspector tests to track regressions. BUG=v8:5568 R=titzer@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2457433002 Cr-Commit-Position: refs/heads/master@{#40633}
2016-10-28 06:47:58 +00:00
- [0] {"functionName":"call_debugger","function_lineNumber":13,"function_columnNumber":24,"lineNumber":14,"columnNumber":4}
- [1] {"functionName":"callDebugger","function_lineNumber":4,"function_columnNumber":25,"lineNumber":5,"columnNumber":6}
- [2] {"functionName":"redirectFun","function_lineNumber":7,"function_columnNumber":24,"lineNumber":8,"columnNumber":6}
- [3] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":19,"columnNumber":2}
- [4] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
Paused #9
Fix detection of BUILTIN functions In the asm.js to wasm pipeline, we generate an entry function with BUILTIN code, but still attached to a TYPE_NORMAL script. This fix avoids trying to set a breakpoint there, resulting in a crash on DCHECK(shared->HasDebugInfo()). Also add two inspector tests to track regressions. BUG=v8:5568 R=titzer@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2457433002 Cr-Commit-Position: refs/heads/master@{#40633}
2016-10-28 06:47:58 +00:00
- [0] {"functionName":"call_debugger","function_lineNumber":13,"function_columnNumber":24,"lineNumber":15,"columnNumber":2}
- [1] {"functionName":"callDebugger","function_lineNumber":4,"function_columnNumber":25,"lineNumber":5,"columnNumber":6}
- [2] {"functionName":"redirectFun","function_lineNumber":7,"function_columnNumber":24,"lineNumber":8,"columnNumber":6}
- [3] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":19,"columnNumber":2}
- [4] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
Paused #10
[debugger] do not use asm validator for debug code. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2492713005 Cr-Commit-Position: refs/heads/master@{#40934}
2016-11-11 15:12:46 +00:00
- [0] {"functionName":"callDebugger","function_lineNumber":4,"function_columnNumber":25,"lineNumber":6,"columnNumber":4}
- [1] {"functionName":"redirectFun","function_lineNumber":7,"function_columnNumber":24,"lineNumber":8,"columnNumber":6}
- [2] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":19,"columnNumber":2}
- [3] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
Paused #11
[debugger] do not use asm validator for debug code. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2492713005 Cr-Commit-Position: refs/heads/master@{#40934}
2016-11-11 15:12:46 +00:00
- [0] {"functionName":"redirectFun","function_lineNumber":7,"function_columnNumber":24,"lineNumber":9,"columnNumber":4}
- [1] {"functionName":"testFunction","function_lineNumber":0,"function_columnNumber":21,"lineNumber":19,"columnNumber":2}
- [2] {"functionName":"","function_lineNumber":0,"function_columnNumber":0,"lineNumber":0,"columnNumber":0}
Fix detection of BUILTIN functions In the asm.js to wasm pipeline, we generate an entry function with BUILTIN code, but still attached to a TYPE_NORMAL script. This fix avoids trying to set a breakpoint there, resulting in a crash on DCHECK(shared->HasDebugInfo()). Also add two inspector tests to track regressions. BUG=v8:5568 R=titzer@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2457433002 Cr-Commit-Position: refs/heads/master@{#40633}
2016-10-28 06:47:58 +00:00
Running test: finished
Finished TestSuite.
Reference in New Issue Copy Permalink