Issue 200803.1: Add DW_LNS_jmp - modify file offset of line number program

Author: Andrew Kelley
Champion: Hafiz Abid Qadeer
Date submitted: 2020-08-03
Date revised: 2021-07-12
Date closed: 2022-01-24
Type: Enhancement
Status: Rejected
DWARF Version: 6
Section, 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:
Partially copied here:

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

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

  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
   - 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.

The motivation seems to be incremental compilation. Proposal asks for a new
opcode in line number table that can be used to jump forward and back in the
line number program. The submission is not clear of what problem this will solve.

Also reading the submission and the github issue, I get the feeling that it is
based on misunderstanding of dwarf. For example, many times it mentions line
number being relative to previous function. The things he is trying to achieve
may already be do-able with the current dwarf. I contacted the submitter for
clarification but did not get any response.

As this proposal asks for adding a bit of control flow in the line table program
without explaining any clear benefit, I think it should be rejected.

The issue also discusses about the padding at the end of the function. I think
that issue has already been handled in 180426.2.

2021-07-12: Added Proposal.
2022-01-24: Rejected.  See issue 180426.2 to insert NOPs in line table.