- User Since
- Mar 9 2018, 11:57 AM (170 w, 1 d)
Thu, May 20
reworked test for .s format and rebasing
May 10 2021
May 6 2021
Addressed code review.
May 3 2021
Yes, this makes sense to me. Another way to put it is that our br_if has the side effect of forcing termination of a "register" lifetime, which is uncommon.
Apr 22 2021
Thanks for doing this, was sorely needed :)
Apr 8 2021
Apr 5 2021
Mar 26 2021
Thanks, that would make sense, since this test was probably adapted from the 32-bit version.
Mar 8 2021
I can land it.. let me pull it in locally and run tests to be sure.
Mar 1 2021
Fixed windows path & test leaving non-temp files behind.
Feb 26 2021
Would it make sense to also run e.g. llvm/test/MC/WebAssembly/debug-localvar.ll with split-dwarf?
Feb 19 2021
Ok, well, I am fine with this patch if @sbc100 is.
Feb 18 2021
This generally looks nice to me.. but my reservations on how useful this is beyond a singular use case still stand: https://github.com/WebAssembly/tool-conventions/issues/162
Added bug todo
Feb 10 2021
Feb 5 2021
simplified and generalized .functype handing
Further refactor the symbol type accessors
Fixes (part of) https://bugs.llvm.org/show_bug.cgi?id=49036
Feb 4 2021
To @pfaffe suggestion changed representation such that TI_LOCAL_INDIRECT emits neither a DW_OP_deref nor DW_OP_stack_value since the result of the expression is already a pointer to the value.
- Moved checking of type to AsmParser label parsing.
- Improved MCSymbolWasm default type handling slightly.
- Added error test case.
Feb 1 2021
Please see DwarfExpression.cpp if you think that Memory is indeed the correct LocationKind in this case. It is this kind not being Implicit that suppresses the DW_OP_stack_value from being emitted at the end of DwarfExpression::addExpression.
Removed the redundant DW_OP_stack_value after DW_OP_deref.
Jan 28 2021
Jan 25 2021
Jan 14 2021
Made it emit a DW_OP_deref instead.
Jan 12 2021
i.e. does it actually matter after that what value the TargetIndex MachineOperand has?
the only difference would be that instead of encoding TI_LOCAL_INDIRECT directly into first argument of DW_OP_WASM_location, that the Dwarf writer would instead change the final argument of DW_AT_location to DW_OP_deref. That change is less elegant in the LLVM code but makes the standardized interface simpler.
This solution is certainly driven by what fits well in the current way LLVM does things, though all the different steps of lowering.
Jan 8 2021
@RReverser is one struct guaranteed to always be passed the same? Here structs are passed by pointer, sometimes they can get passed in registers/locals..
Jan 7 2021
Jan 5 2021
@dblaikie Added you for review since this modifies common DWARF code, would love to hear if that is problematic or not. It would seem not, since we're the only users of these TI's it seems, and the new code is generic enough that it could work for future targets using TIs?
Dec 10 2020
Dec 3 2020
Has new tests that pass, and checked by hand that the one test where the code contents changed passes wasm-validate :)
Well, these tests are not going to tell us if the generated instructions make any sense, but ok..
Nov 30 2020
Looks like we don't have a wasm32 test for this?
Nov 13 2020
Nov 12 2020
After discussion with more Wasm+DWARF interested parties, it became clear that asking producers and consumers of DWARF to treat DW_FORM_addr as anything other than architecture dependent is going to be problematic, so the way forward for now is to make this field 64-bit on wasm64 as intended, and leave it 32-bit on wasm32.
@yurydelendik note that wasm64 is an LLVM-level construct, in general Wasm we may one day have multiple memories, which means that "being 64-bit" is a property of each load/store instruction individually. So assuming we have a DWARF section associated with a possibly mixed mode Wasm module, there's no way to determine the size of DW_AT_low_pc or DW_FORM_addr from the module.
Nov 10 2020
As for how to make a test for this.. The code before this patch would (I assume) write 4 extra bytes, which would cause dwarfdump to show incorrect information. Our existing test however wasn't affected. So to cover this patch against regression would require some larger dwarfdump example I guess..
@dblaikie Confusingly, these are all different: function pointers at runtime (in a Wasm VM) are 32-bit indices. LLVM function pointers are 64-bit in wasm64 for consistency, but get truncated when lowered in Isel. Then here we have a 3rd kind of code pointer, just for DWARF, since Wasm doesn't have the concept of a pointer to an instruction inside a function (which DWARF needs for DW_AT_low_pc, and we need to relocate).
Note this has not been tested on non-Wasm platforms yet. Wanted to first get feedback if this is a legit way to solve the problem, or if there are better ways.
MC parts generally look good to me.
Oct 30 2020
The paths in this test only worked on Windows. A fix has been pushed in b093eba08478db387fc2765dee1e1bf2d64fcf68
updated test for --show-form and added TODO