DWARF Standard


HOME
SPECIFICATIONS
FAQ
ISSUES



200803.1 Andrew Kelley Add DW_LNS_jmp - modify file offset of line number program Enhancement Open


Section 6.2.5.2, pg 162

The DW_LNS_jmp standard opcode takes a single signed LEB128 operand, which is a 
byte offset affecting not the virtual address program counter, but the file offset 
of the Line Number Program itself. The new Line Number Program position is adjusted 
by this offset.

Use case: This allows line number programs to move the control flow of the line 
number program itself forward and backward by arbitrary amounts. This facilitates 
incremental compilation, because it allows individual functions to be added and 
resized without having to move other ones within the .debug_line section.

Related downstream issue report: https://github.com/ziglang/zig/issues/5963
Partially copied here:

for each file: (starts out at line 1 column 0)
  DW_LNS_set_file

  for each function (sorted according to source order):
    DW_LNE_set_address  xx xx xx xx (relocatable address, move with the function)
    DW_LNS_set_prologue_end
    DW_LNS_advance_line (relocatable, advance to the opening `{`)
    DW_LNS_copy
    process the IR debug info instructions using DW_LNS_advance_line, DW_LNS_advance_pc, DW_LNS_copy
    DW_LNS_set_epilogue_begin
    DW_LNS_advance_line (advance to the terminating `}`)
    DW_LNS_copy
    NOPs used as padding so the function can grow

  DW_LNE_end_sequence
  NOPs used as padding so the file can grow


This strategy depends on "NOPs used as padding". There are two ways currently to
 achieve this effect:

 * Using an extended opcode with an arbitrary (unsigned) length and DW_LNE_user_hi
   - Unfortunately not supported by gdb (see https://sourceware.org/bugzilla/show_bug.cgi?id=26333)
   - Only allows skipping forward, not backward

 * Using {DW_LNS_negate_stmt, DW_LNS_negate_stmt} as a 2-byte NOP
   - Requires writing unnecessary bytes to the .debug_line section (worse compilation performance)
   - Requires debug info consumers to do unnecessary work (worse debugging performance)
   - Also only allows skipping forward

DW_LNS_jmp would allow an incremental compilation strategy that supported adding 
and growing functions by putting them at the end, and patching up the DW_LNS_jmp 
offset with a fixed-size ILEB128, while still maintaining the advantage of functions 
line info being relative to the previous function from the source file, making 
incremental compilation of a single function O(1) edits to the .debug_line section. 
Without this proposal, the functions above must be sorted according to source order, 
however with this proposal, they may be in any order that causes the least amount of
file system operations when performing an incremental compilation.



All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2007-2020 by DWARF Standards Committee.