[Dwarf-Discuss] Line table "no-op" sequence

[paul.robinson@sony.com]

> One technique you haven't mentioned is to stretch out LEB128 numbers
> with extra 0x80's. 

Yeah, I kind of don't like abusing the LEB format like that.  Maybe
for one or two bytes, but not arbitrarily long strings (as you note,
some consumers will decide it's corrupted data).

> When doing an incremental link, gold will pad the .debug_line section
> with a dummy line number program of appropriate length (minimum 29
> bytes). Here are the relevant comments:
> ...
>   // We set the header_length field to cover the entire hole, so the
>   // line number program is empty.

I have a consumer that whines if the header_length doesn't exactly match
the fields as defined in the appropriate DWARF version.  But maybe I can
make it tolerate this.

>   // Some consumers don't check the header_length field, and simply
>   // start reading the line number program immediately following the
>   // header.  For those consumers, we fill the remainder of the free
>   // space with DW_LNS_set_basic_block opcodes.  These are effectively
>   // no-ops: the resulting line table program will not create any rows.

I still say it's syntactically invalid unless it ends with end_sequence.
But otherwise this is "great minds think alike."

> I use a similar technique to pad the .debug_info and .debug_types
> sections. Those are a bit easier, since we can simply pad the actual
> data area with zeroes.

Again I think I have a whiny consumer but it can probably be fixed.

> > 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.
> 
> Another thing you can do is "hide" stuff inside an undocumented
> extended opcode. Because extended ops always declare their length, you
> can make a single extended op cover whatever hole you have (as long as
> it's at least 3 bytes). If you use an extended opcode of, say 0x7f,
> which hopefully no one has implemented, any conforming DWARF reader
> will simply skip over it without complaint.

Ooh I like that.  Should we officially reserve an opcode for this?

> You can also use DW_LNS_advance_pc with an arbitrary length LEB128 "0".

That's abusing the LEB format again.  I like the undefined extended
opcode idea best, although to satisfy my own pedantry I'd still follow
it with an end_sequence.

Thanks!
--paulr