Re: dwarf2 basic block start information

[Richard Henderson <rth at redhat dot com>]

On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote:
> Since the cvs version of gas supports extensions for the dwarf2 
> basic_block location information, I thought I could try to add support 
> to gcc for this feature.

I had been working on this, but got distracted.  I hope to get
back to this soon, and have the feature implemented for gcc 4.2.

> My use of this feature is related to binary 
> code analysis: being able to gather the bb boundaries through gcc's 
> debugging output would save me reverse engineering it from the binary 
> code itself.

Exactly so for Red Hat's desire for this feature.

And, to be specific, I was planning on marking extended basic
block boundaries (i.e. labels) and not all basic blocks.  The
code movement we have in mind would be able to handle calls
and jumps, and the target environment doesn't use non-call
exceptions, so there's no trapping insns to worry about.

> 1) is it expected that some rtl optimization passes would bork the 
> BASIC_BLOCK notes ?

Yes.  They're completely unreliable at the end of compilation.

> 2) if it is, are these known culprits and would there be interest in 
> patches to try to fix this ?

There's a pass that needs a total rewrite.  We'd be delighted if
someone would rewrite it, but no one seems to want to.

> 3) have anyone an idea of which passes might be the culprits ? (it might 
> save a lot of time wandering through gcc sources)

reorg.  It's delayed branch scheduling.

Your patch isn't nearly sufficient.  There are other issues that
need handling, including inline assembly.  This is the reason that
cvs gas also supports marking *all* labels.


r~