[llvm] [MC][DebugInfo] Emit linetable entries with known offsets immediately (PR #134677)

[Jeremy Morse via llvm-commits]

jmorse wrote:

I believe this latest version now gets it right (TM) for RISCV as well -- observe the changes to the encoding of dwarf-riscv-relocs.ll. The assembly for this file reads:

    00000000 <main>:
       0: ff010113      addi    sp, sp, -0x10
       4: 00112623      sw      ra, 0xc(sp)
       8: 00812423      sw      s0, 0x8(sp)
       c: 01010413      addi    s0, sp, 0x10
      10: 00000097      auipc   ra, 0x0
                        00000010:  R_RISCV_CALL_PLT     ext
                        00000010:  R_RISCV_RELAX        *ABS*
      14: 000080e7      jalr    ra <main+0x10>
      18: fe042a23      sw      zero, -0xc(s0)
      1c: 00000513      li      a0, 0x0
      20: 00c12083      lw      ra, 0xc(sp)
      24: 00812403      lw      s0, 0x8(sp)
      28: 01010113      addi    sp, sp, 0x10
      2c: 00008067      ret

i.e. there's a linker-relaxable relocation at address 0x10. The line table retains a `DW_LNS_fixed_advance_pc` opcode across that boundary, which is controlled by the relocation for .debug_line (which is in the test too). However for the latter section from 0x1c onwards, which isn't relaxable and is in one plain MCDataFragment, we switch to using DWARF linetable special opcodes instead, a smaller and more optimal encoding. I believe this is the correct behaviour: the linetable address-differences remain relocatable across boundaries that are relaxable, but the relative address-differences can be fixed for portions that aren't relaxable.

Thanks for the blog post at https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation , that's educated me about what's going on here @MaskRay .

https://github.com/llvm/llvm-project/pull/134677