[Dwarf-discuss] Purpose of basic_block flag in line number table?

[Mathieu Lacage]

On Wed, 2006-07-19 at 20:40 -0700, Michael Eager wrote:
> Cary Coutant wrote:
> > I've got a question about the basic_block flag in the DWARF line  
> > number table.
> > 
> > It seems to me that the point of this flag is to enable efficient  
> > single stepping -- i.e., instead of stepping one instruction at a  
> > time until you get to a different line number, the debugger could  
> > look down the line table until it got to either a new source line or  
> > the end of a basic block. If it found a new line before the end of  
> > the basic block, it could set a breakpoint and free-run, fairly  
> > confident that it'll hit that breakpoint. Otherwise, it could set a  
> > breakpoint at the end of the basic block, then single step to  
> > establish where it's going next (which will probably be at a new  
> > source line).
> > 
> > Is this in fact what the flag is for, or is there some other purpose  
> > that I'm overlooking?
> 
> I believe that the basic block flag was added for profiling
> source code, not for optimizing stepping.  I don't know if any
> tools are actually using the flag -- I'd be interested in hearing.

The way I interpreted the basic_block flag was as an indication of the
start of a basic block at the assembly level (which has little to no
relationship to the source code itself). I actually tried to use this
interpretation of the flag to reverse-engineer at runtime the location
of the binary code basic blocks. This did not work very well due to my
being unable to find any decent producer of such a flag.

If you wonder why being able to spot basic block boundaries is useful,
the answer is easy: it can be used to instrument running code to insert
instrumentation instructions by modifying the code once loaded in
memory. On x86 and platforms which have no fixed-size instruction slots,
we need to know the location of the basic blocks to make sure we never
insert an instrumentation instruction which crosses these boundaries
Doing so would risk allowing running code to jump in the middle of our
instrumentation instruction which would be unlikely to do anything
useful.

> 
> I not sure how a debugger might use the basic block flag to
> optimize single stepping, assuming that this means executing a
> single line.  If you are stepping over calls, then finding
> the next line should be independent of the basic block flag.
> 
> Also, DWARF indicates the start of a basic block, not the end.
> I don't know that you can assume that the line before a basic
> block is the end of a preceding basic block.


If you interpret the basic block flag as I suggested above, then, the
start of a basic block indicates the end of the preceding basic block

> 
> > What about step-into as opposed to step-over? The DWARF spec extends  
> > the concept of basic block to include calls, so there'd be no way for  
> > the debugger to step into the call and stop without single stepping  
> > or disassembling instructions.

Maybe I was smoking crack when I tried to do this.

Mathieu
--