Looks good. Thanks
Mon, May 6
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)
Use Sym->isLive; start dead function offset at 0.
Aug 28 2018
Use for (const auto &Op :
Aug 22 2018
Rebased on top of D48994
Aug 21 2018
Aug 20 2018
Aug 14 2018
Aug 10 2018
Jul 31 2018
Jul 24 2018
Ish - but existing debuggers/linkers already tolerate this sort of debug info - so it'd be ideal/better if WAsm did too. Any address derived from zero would be considered invalid/uninteresting. (similarly for the debug_info itself - you'd find similarly confusing data, where functions start at zero and are X bytes long - so technically a bunch of non-zero bytes are covered by that range, but currently it seems existing debuggers/linkers are OK with this contract too).
Jul 18 2018
I'm still not sure I understand why writing zero here is not a good idea.
I believe for other architectures, when the linker emits debug info for a dead function, it treats relocations pointing a dead section as if it were pointing to address zero. Is there any reason to do that differnetly for wasm?
Jul 17 2018
Jul 16 2018
Per discussion at the WebAssembly toolchain meeting, this solution is too complex. I going to close this WIP in favor more simple solutions such as disabling debug info during optimization, or moving optimization out of the lld.
Do you happen to have a smaller/reduced reproducer?
- Reducing the test case further: remove attributes, lifetime markers and non-"a" variable metadata.
- Add test for MoveAndTeeForMultiUse changes