[cfe-commits] r51553 - in /cfe/trunk: include/clang/AST/Type.h lib/CodeGen/CGDebugInfo.cpp lib/CodeGen/CGDebugInfo.h lib/CodeGen/CGStmt.cpp lib/CodeGen/CodeGenFunction.cpp

[Eli Friedman]

On Sun, May 25, 2008 at 8:13 AM,  <Sanjiv.Gupta at microchip.com> wrote:
>> The issue I was getting at doesn't exist, at least not with
>> the way llc uses debug info.  llc doesn't really support the
>> debug spec properly in terms of regions, and it actually
>> doesn't mind if you leave out the function end marker.
>>
>> That said, if you have an llc port that actually wants
>> regions/functions to start and end consistently, you're
>> probably going to have to generate start/endregion markers
>> differently from the way you're doing it right now.  The
>> issue is that even for a simple function like "int a(int a)
>> {return a;}", passes like simplifycfg will zap the function
>> end marker.
>>
>> -Eli
>>
> Yes, we need regions/functions to start and end consistently.
> Our debug info which is a COFF symbol table depends upon the correct
> order of these.
> What suggestions do you have to make these things generated
> consistently? That will be a great help.

Well, I don't know too much about how this sort of stuff works deep in
codegen, but depending on the ordering of blocks in codegen is likely
to be very fragile.  On the front-end side, with the  current
intrinsics, I think it makes the most sense to guarantee that every
start/end region is matched along every possible path through the
program.  For the function-level regions, this is easy: just emit the
start at the beginning of the function and the end before every
return.  (This is something like what I implemented in my checkin to
unbreak debug info.)  For block-level regions, this gets more tricky
because of break, continue, and goto; you probably need to be able to
calculate the entire stack of regions for any given jump target.

(Another possibility is for the subregions, to not bother emitting the
end-region markers, instead just using start markers to indicate
entry/exit, but that's a bit different from the description of the
current semantic, so I don't know if it's worth trying.)

That said, I don't know much more about the debug info format than
what's at http://llvm.org/docs/SourceLevelDebugging.html. Feel free to
ignore me if you have a better understanding of what you're doing.

If you haven't sent an email to llvmdev yet, that might be worth doing
to see if anyone there has anything to say about the debugging info
format and regions.

-Eli