Re: Line Number Table Issue

[Michael Eager <eager at eagercon dot com>]

Brian Nettleton wrote:
> 
> The current spec always for, and in fact says a pipeline scheduling code
> generator should default the is_stmt boolean to "false".  This is wrong in
> that the first instruction of any sequence would seem by definition to be
> the beginning of a source line!  It is allowed for a compiler to generated
> instructions which aren't associated with any line number in which case the
> line number is identified as 0.  A debugger would largely ignore these
> instructions anyway (especially the is_stmt boolean for these).  So even if
> an optimizing compiler generated instructions which aren't associated with a
> line number then eventually the first instruction generated for an actual
> source line would still seem to be the first instruction for that source
> line.

This may not be the case.  

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.

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.

> 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.

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.    

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