[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).
> 
> I don't think it's abuse of the format at all, as long as you don't go
> over the reasonable maximum length. There's nothing in the spec that
> requires an LEB128 to be minimum length,

Okay, fair.

> >>   // 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."
> 
> What DWARF says is: "Every line number program sequence must end with
> a DW_LNE_end_sequence instruction which creates a row whose address is
> that of the byte after the last target machine instruction of the
> sequence."
> 
> If the line table program contains no sequences (i.e., it's empty),
> you don't need an end_sequence instruction.

I had interpreted this to mean that a non-empty line-number program had 
to end with end_sequence; but you are saying that a line-number program
that creates no rows therefore has no sequences, therefore does not have
to end with end_sequence.  That's why smearing with set_basic_block ops
is fine, you use as many as you need to fill up the hole, and done.

Given that sequences are actually described sequences of target machine 
instructions, not line-number program instructions, that sounds okay.
(And it looks like my whiny consumer won't complain either, for once.)

> We need to crack down on whiny consumers. They defeat the
> extensibility that we designed into DWARF.

I'll have a go at the LLVM dumper, when I get a chance.

> A DW_LNE_comment opcode? You could propose it for DWARF 6.

I think I will!

Thanks,
--paulr