Issue 200803.1: Add DW_LNS_jmp - modify file offset of line number program
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.
Proposal
========
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.
