Recently I had a chat with one of the linker developers on my team. He was trying to work out how to insert what would effectively be a no-op sequence into the line table.
One reason to do this is if a producer wanted to pad the line table for a compilation unit, either for alignment purposes or to leave room for expansion (e.g. to simplify incremental linking). Another reason is if the linker decides to omit a function (e.g. if nothing references it, the code can be dead-stripped) then it could overwrite the related sequence(s) in the line-number program, rather than remove then and shrink the entire line table. Arguably you could just increase the length in the header, but then a dumper (or other consumer) could become confused by whatever is left after the last sequence. I think the padding needs to make sense to a consumer; i.e., syntactically it needs to look like another sequence. In order to look like a sequence, the padding would have to end with an end-sequence extended opcode, which is three bytes. Poking around in the spec for something that would effectively behave as a one-byte NOP, it looks to me like there are a few standard opcodes that take no operands and do not generate rows in the virtual line table: DW_LNS_negate_stmt DW_LNS_set_basic_block DW_LNS_set_prologue_end DW_LNS_set_epilogue_begin Using one of the first two has the advantage that they are defined as of DWARF v2, so the linker doesn't have to pay attention to the DWARF version of the line table. DW_LNS_set_basic_block is probably a tiny bit more efficient than negate_stmt, as the former writes a flag while the latter does a read+write. The requirement to end the padding with an end-sequence does mean that the padding has to be at least three bytes long, but padding using this tactic can be any amount larger than that. The specification says that DW_LNE_end_sequence does create a row in the table, "whose address is that of the byte after the last target machine instruction of the sequence." In general, this opcode can't know where the last instruction is, or how long that instruction is, therefore normally it would be preceded by some opcode that sets the address register. That is, end-sequence doesn't modify the address register before emitting the row. In the padding scenario, the address would be zero, giving us a zero-length sequence. Hopefully this would not confuse any existing consumers too badly. What do people think? I'm happy to write up a short bit for the wiki Best Practices page. (I'll probably be embarrassed to find that this was discussed before and I've forgotten, but it does seems worth a note on the wiki.) Thanks, --paulr _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
