Re: Question about interpretation of .debug_line sections

[David Anderson <davea at quasar dot engr dot sgi dot com>]

Matthew Gretton-Dann <Matthew.Gretton-Dann@arm.com> writes:

>        If space were not a consideration, the information provided in
>        the .debug_line section could be represented as a large matrix,
>        with one row for each instruction in the emitted object code.
>
>This seems to indicate that a .debug_line section should be interpreted
>in a similar way to a .debug_frame section, i.e. that changes to the
>source position information for a particular code location overwrite the
>information already recorded for that code location.
[...]
>The difficulty I have with this interpretation is that it doesn't allow
>some optimisations to preserve the debuggability of an image.  For


The interpretation is correct and your observation is correct,
according to a seeming-consensus on this topic a few months ago.

My US$0.02:

Whether having multiple source-declarations per instruction
would "preserve the debuggability of an image" is really an
open question.  We understand what you mean and others have
made the same observation you did. Not everyone is convinced it
preserves debuggability meaningfully.

Optimizers do lots more than just merge
common code sequences, and it's not clear that the small
step you mention is as important as other problems
in attempting to debug optimized code.

Putting on my committee hat for a moment, I'd suggest
that a working and proved-useful debugger and compiler
(and a good write-up of what was done and why and how well it worked!)
would go a long way toward convincing folks that a certain
set of debug-optimized-code features was the right set
to standardize on. 

David Anderson, speaking for myself.