Agree with all the changes
Wed, Jan 15
Closing in favor of D71681
Dec 19 2019
Dec 18 2019
Dec 16 2019
add llvm-dwarfdump test
Dec 6 2019
Dec 2 2019
Nov 18 2019
Use TargetIndex operands in DbgValue to track WebAssembly operands locations
Nov 6 2019
we'd need to ensure that the frame base stays in the designated local for the whole function, correct? i.e. we'd have to ensure it never gets stackified, which it currently could, right?
Nov 4 2019
Rebase D52634: [WebAssembly] Add DBG_VALUE with local operands location in WebAssemblyExplicitLocals pass
Jul 15 2019
the WebAssemblyDebugValueManager constructor could just apply an additional filter on collected DbgValues, that the LiveInterval/ValueNumber the DBG_VALUE refers to is the defining instruction.
Jul 13 2019
Let's work toward getting this landed!
@yurydelendik Your note mentioned that you reverted the breg version based on some kind of incompatibility, can you say more about that?
Jul 12 2019
I've added some changes to the patch that makes collectDebugValues behave in the way I described, returning all debug users of a VReg, optionally limited to only the basic block of the source MachineInst. This should be useful for testing; and it's immediately caused the test/DebugInfo/WebAssembly/dbg-value-move-reg-stackify.mir  test to fail. The output is:%0:i64 = ARGUMENT_i64 0, implicit $arguments dead %1:i32 = I32_WRAP_I64 %0, implicit-def dead $arguments dead %1:i32 = CALL_i32 @bar, implicit-def dead $arguments, implicit $sp32, implicit $sp64 %2:i32 = CALL_i32 @bar, implicit-def dead $arguments, implicit $sp32, implicit $sp64, implicit-def $value_stack, implicit $value_stack DBG_VALUE %2, $noreg, <0x5490d00>, !DIExpression(), debug-location !DILocation(line: 359, column: 12, scope: <0x548f5f0>) DBG_VALUE %2, $noreg, <0x5490cb0>, !DIExpression(), debug-location !DILocation(line: 358, column: 12, scope: <0x548f5f0>) DBG_VALUE %2, $noreg, <0x5490a50>, !DIExpression(), debug-location !DILocation(line: 357, column: 12, scope: <0x548f5f0>) CALL_VOID @foo, %2, implicit-def dead $arguments, implicit $sp32, implicit $sp64, implicit-def $value_stack, implicit $value_stack RETURN_VOID implicit-def dead $arguments
While I don't know webassembly, it seems clear that a) the test post-SSA, and b) the test expects collectDebugValues to only return DBG_VALUEs that refer to the same vreg def that the source instruction does.
Is that a fair assessment, or some kind of test artefact? That behaviour is almost certainly achievable after this patch lands, although it might require more plumbing somewhere.
Jul 1 2019
Awkwardly collectDebugValues relies on a behaviour that this patch will mostly undo, specifically, that DBG_VALUE insts are placed after the defining instruction. collectDebugValues will work sometimes, but will "miss" DBG_VALUEs much more often that it does now.
@yurydelendik Would this change be OK for WebAssembly debug value handling?
May 6 2019
Looks good. Thanks
Mar 5 2019
Mar 4 2019
@jingham is this patch good to land?
Feb 7 2019
Could you add a test for this setting to the ./functionalities/jitloader_gdb/TestJITLoaderGDB.py test?
- Remove enable-jit-breakpoint option
- Add tests
Feb 4 2019
- Change to on/off/default property.
Fix GetEnableLoaderForDarwin name
Jan 16 2019
Minor changes to comment; move #include
Jan 15 2019
Add simple test
- revert breg use due to incompatibility with DWARF definition
- rebase to git llvm-project
Jan 14 2019
Top comment fix
- Prune unused #include
- Fix comments
- Reduce default size of vector to 2
- Reverse insert order for move/clone
Jan 11 2019
- Fix WebAssemblyDebugValueManager::move
- Remove DebugValueManager::reMaterialize
And another question: I haven't been a reviewer for your other debug info related CLs so I don't know, but are there any other places or your pending CLs that can make use of this new class?
- Fix trivially clonable instruction moving/cloning
Revert bad test change
Oh and I think we need test cases for
- Rematerializing a def in another BB that has DBG_VALUE attached
- Move WebAssembly::DebugValueManager into WebAssemblyUtilities.*
- Fix testing of dbg-value-move-reg-stackify.mir
Jan 10 2019
Remove TII param from clone()
- Move MachineInstrAdjacentDebugValues
- Use CloneMachineInstr
Jan 9 2019
I haven't finished reading other parts, but I think I should understand this AttachedDebugValues constructor first to proceed.
- Use collectDebugValues
- Rename AdjacentDebugValues and DefDIs
Jan 7 2019
fix code style
Dec 19 2018
Come to think of it, might we actually want the possibility of constant offset in addition to the "kind" and index field, e.g. for cases where the value is actually a pointer?
@aprantl Is the advantage of your suggested approach just that we don't have to define a new expression type? Obviously the interpretation is not the same as DW_OP_breg on other targets so as you say, either way there would have to be special logic in all the tools that consume it. Is this kind of repurposing of builtin primitives common?
I'm not against this approach, I was just trying to point out that an alternative less invasive encoding could be used that might be less confusing to existing consumers of debug information.
Dec 18 2018
Replace DW_OP_wasm_location with DW_OP_breg
I also found that the tools (e.g. LLVM or LLDB) are eager to know about number of registers (which we cannot determine) to allocate internal structures.
What I was thinking of was to define exactly three WASM DWARF register numbers: wasm_reg_local, wasm_reg_global, wasm_reg_stack and use DW_OP_breg regnum offset like you would use the new special operation introduced by this patch.
Can you explain how this new operation is meant to work?
@aprantl, here is some description of what we are trying to achieve: https://github.com/WebAssembly/debugging/issues/1#issuecomment-448237641
In the nutshell, the WebAssembly extensions for the DWARF expression will allow us to express WebAssembly specific locations such as for locals, globals and operands stack. The consumers of this information will be limited to LLVM tools, web browser debuggers and AOT/JIT WebAssembly compilers.
Does WebAssembly have a concept of registers? You could just define three additional register numbers for WebAssembly and address a stack slot as DW_OP_breg [wasm_stack_register] + 3 etc.. This would need less support in all the involved tools. The link says that it was considered, but rejected, but there is no mention as to why.
Nov 9 2018
Change DW_OP_WASM_location op to 0xED.
Can you explain how this new operation is meant to work?
There was a question about how easy it will be to reuse or modify LLDB to use with such extension (DW_OP_WASM_location). I looked at DWARFExpression::Evaluate and, I think, it will not be a problem to add support for that. It might be even easier than try to emulate registers mapping to some WASM local or stack operand.
Nov 2 2018
Oct 4 2018
Further reduced by @aheejin test case
And I don't think we need the BEFORE check... what I meant by the 'before' check in the comment above was, before your fix, the wrong code sequence generated was like that.
Further reduction of cfg-stackify-dbg-skip.ll
Would bugpoint help here? Its specifically designed to minimize test case I think although I don't have a lot of experience with it myself.
Minimize test case; fix its comment
.. you can pass multiple -run-pass flags to llc, like llc -run-pass wasm-reg-stackify -run-pass wasm-reg-coloring .... Maybe we can start from mir just before the RegStackify pass and make llc run all passes from RegStackify to CFGStackify. I think it's worth trying. If this fails for some other reason, we can bring back .ll test case...
Revert test to .ll form, but ensure valid input before wasm-cfg-stackify pass
Oct 3 2018
Add mir test
Add test comment
Why should we skip debug instructions when searching for block start?
Sep 27 2018
Sep 26 2018
We we revert this or get it fixed? Its currently breaking the wasm waterfall: https://wasm-stat.us/console
Sep 25 2018
This seems to have broken some of the emscripten tests (binaryen2.test_poppler and binaryen2.test_the_bullet) that we run on the wasm waterfall:
Sep 24 2018
Add instructions how to regenerate dbg-value-move*.ll files
Rebase (adjust test/DebugInfo/WebAssembly/dbg-value-move.ll)