[PATCH] D74781: Wasm-ld emits invalid .debug_ranges entries for non-live symbols

Paolo Severini via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 26 14:42:11 PDT 2020


paolosev added a comment.

>> Yes, I managed to get a .debug_loc section also for Wasm with similar code, and debug_loc does not seem to present the same problems with GC'd functions.
> 
> Even without your patch? If without your patch you were getting range list entries of zero/zero, I'd expect you to get debug_loc entries with zero/zero too. Any ideas why it doesn't? They should be a similar pair of relocations (though it looks like your fix should work for debug_loc too, which is good).

Looking at the generated DWARF, this patch does not change the offsets for debug_loc.  Like in the example above, there are loc entries for variables in the deleted function `f2`:

  0x0000004a:   DW_TAG_subprogram
                  DW_AT_low_pc    (0x0000000000000000)
                  DW_AT_high_pc   (0x000000000000004d)
                  DW_AT_frame_base        (DW_OP_WASM_location 0x0 +1, DW_OP_stack_value)
                  DW_AT_GNU_all_call_sites        (true)
                  DW_AT_linkage_name      ("_Z2f2Ri")
                  DW_AT_name      ("f2")
                  DW_AT_decl_file ("C:\dev\llvm-project\release_x64\T\main.cc")
                  DW_AT_decl_line (3)
                  DW_AT_type      (0x000000cd "int")
                  DW_AT_external  (true)
  [...]
  0x00000071:     DW_TAG_variable
                    DW_AT_location        (0x00000000:
                       [0x00000014, 0x0000001b): DW_OP_consts +42, DW_OP_stack_value
                       [0x00000026, 0x0000002d): DW_OP_consts +21, DW_OP_stack_value
                       [0x0000003f, 0x0000004d): DW_OP_WASM_location 0x0 +2, DW_OP_stack_value)
                    DW_AT_name    ("i")
                    DW_AT_decl_file       ("C:\dev\llvm-project\release_x64\T\main.cc")
                    DW_AT_decl_line       (4)
                    DW_AT_type    (0x000000cd "int")

The entries seems to assume that the deleted function starts at offset 0, and ends at 0x4d, and this is true also without the patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74781/new/

https://reviews.llvm.org/D74781





More information about the llvm-commits mailing list