REVISED PROPOSAL 517.2 - Line Number Information default_is_stmt

["Brian Nettleton" <briann at estc dot com>]

Summary
=======

This is an editorial change to clarify the default_is_stmt
boolean in the Line Number Information section.


Proposal
========

Change the italicized paragraph under item "5.
default_is_stmt (ubyte)" in section 6.2.4 to be (still
italicized):

  <i>A simple approach to building line number information
  when machine instruction sequences are emitted in the
  order implied by the source program would set this to
  "true," and every entry in the matrix would represent
the
  beginning of a statement.  More sophisticated
instruction
  sequences might require multiple entries for the same
  source position, but usually only one entry is
identified
  as the beginning of a statement.  These sophisticated
  sequences would require the use of the
DW_LNS_negate_stmt
  in the statement program and may set default_is_stmt to
  either "true" or "false".  One entry should always be
  specified as the beginning of a statement.</i>


Discussion
==========

Replaced the words "statement boundary" with "beginning of
statement" simply to be more consistent with other parts
of section 6.2.  Neither of these terms is well defined,
this is intentional because the definition is a quality of
implementation and/or style issue (i.e. it is a bag of
worms).

Replaced "code generator" with "machine instruction
sequences" to stay away from implementation details and
arguments over whether a particular code generator is
sophisticated/pipelined/etc. or not.

Also allowed for cases where a source position may have
multiple entries marked "beginning of statement".  This
may occur with inlined functions which are called more
than once (and probably other areas as well).

The minutes from the last meeting indicated that using
DW_LNS_negate_stmt would imply that a code generator
specify FALSE for default_is_stmt.  This hadn't occurred
to me before reading the minutes and might be the source
of mine (and others) confusion!  This may have even be the
meaning of the original paragraph in the 2.0
specification!  However this is why it doesn't make sense
to me and why I don't think it's justified.  First
regardless of the setting of default_is_stmt any line
number table is representable because DW_LNS_negate_stmt
can always be used to set the register correctly (i.e. the
default_is_stmt boolean is not required to represent some
line number table which can't be represented without it).
The usefulness of the boolean when "true" for the simple
instruction sequences described in the italics is pretty
clear: it reduces the size and complexity of the statement
program.  My perception of the usefulness for more
sophisticated sequences is still in reducing the size of
the statement program, i.e. a quality of implementation
issue.  I don't see how it's useful for a consumer to know
in advance, via default_is_stmt equal to "false," that
DW_LNS_negate_stmt is used, and I don't think a consumer
can rely on this behavior from the 2.0 spec.  I also
believe that "optimally sized" statement programs, for
many implementations including sophisticated/optimizing
ones, would still set this boolean to "true".  Admittedly
there are at least some possible implementations/code
sequences (like when "beginning of statement" is something
like in the Caroline Tice paper) where these tables may be
optimally sized when the default_is_stmt is "false".  If
we agree that the justification for the default_is_stmt
boolean is to reduce statement program size and/or
complexity then I don't think we should indicate how it is
set, even in italics.  It is purely a quality of
implementation issue (and a quality optimizing
implementation might set it "true").