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~
