RE: Line Number Table Issue

["Brian Nettleton" <brian dot nettleton at windriver dot com>]

Michael Eager wrote:

> In a common implementation of a for loop, the
> instructions to increment
> the index appear before the actual start of the code.
> For example:
>
> 	for (; i < 10; i++) { <whatever> }
>
> might be generated as
>
> 		    goto for_start
> 	for_inc:    i = i + 1
> 	for_start:  if (i >= 10) goto for_end
> 		    < whatever>
> 		    goto for_start
> 	for_end:
>
> Whether this is good code or not, it is a reasonable
> implementation for
> the for loop.  And the "start" instruction is not the
> earliest instruction.
>


This is a good example that I didn't think of as why the is_stmt
boolean is needed.  I'm not arguing to delete the is_stmt
boolean, just removing the default_is_stmt boolean.

> Things get much more interesting when common
> subexpression elimination
> and code motion move parts of a statement some
> distance before the logical
> start of the statement.
>

Yes, I did think some about these kinds of issues.  I thought
that a compiler would simply mark these kinds of things with a
line number of 0, and it would make most sense for a debugger to
simply leave them alone (at least from a line number table point
of view).  I would agree that it should be up to the compiler
writer whether some extensive code motion resulted in moving the
start of the source line or not. My argument should be refined
somewhat, code motion may result in the is_stmt boolean being
false for the first instruction for a source line.  I still think
that the default_is_stmt boolean is at least confusing.

> > One might ask "Do we need an is_stmt boolean anyway?
>  Can't a debugger
> > simply identify the first instruction associated
> with a line number and use
> > this for setting breakpoints and then deal with the
> other situations as
> > needed?"  The answer is that yes we do need the
> is_stmt boolean to handle
> > situations where a source line is expanded multiple
> times in a file.  For
> > example an inline subroutine which was called twice
> would have it's source
> > lines "begin" twice in the instruction sequence.
> It's not clear that this
> > is why the DWARF 2 spec originally included this
> boolean, but this probably
> > does justify it's existence.
>
> is_stmt provides a way for the compiler to tell the
> debugger where the
> start of the statement occurs, and eliminates the
> debugger having to make
> the assumption that the first instruction is the start
> of the statement.
>

Yep.  I'm in agreement that the compiler is the right place to
make the decision about which instruction is the beginning of a
source line.


> On another point, a compiler which was given the following line
>
> 	a = 1; b = 2; c = 3;
>
> might reasonable generate multiple line table entries
> each of which has
> the same line number, and each of which has is_stmt true.
>
> --
>
> It sounds like the root problem is that the compiler
> you are working with
> is generating the line information incorrectly, since
> it does not mark any
> instructions as being the start of a statement, and
> (evidently) sets the
> default_is_stmt to false.
>
> I'm much more likely to think that the solution to
> your problem is to
> correct the bug in the compiler rather than change the
> Dwarf standard.
>

Yes, I think I would tend to agree that this compiler is
interpreting the standard incorrectly.  However the pesky last
sentence in 6.2.4 item number 5, "A pipeline scheduling code
generator would set this to "false" and emit a specific statement
program opcode for each instruction that represented a statement
boundary," seems to provide a leg for this compiler to stand on.
Admittedly this sentence is italicized so isn't really part of
the standard, but I think it's very misleading.  To tell the
truth I don't really know what the second half of this sentence
means, although the first half seems to clearly indicate that if
I have an instruction scheduler then I should set the
default_is_stmt to false (which I think is not necessarily good
advice).  I would also support an editorial change to simply
remove this sentence, although I think the mere existence of the
default_is_stmt is confusing and allows for strange
interpretations.

> --
> Michael Eager	 Eager Consulting     eager@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>