[LLVMdev] Debug Information for LLVM 2.6 and TOT

[John Criswell]

Devang Patel wrote:
> Hi John,
>
> On Wed, Nov 4, 2009 at 12:04 PM, John Criswell <criswell at uiuc.edu> wrote:
>   
>> Dear All,
>>
>> 1) I recall reading somewhere that a few optimizations in LLVM 2.6 strip
>> away debug information when such information interferes with
>> optimization.  Is this correct,
>>     
>
> Yes.
>
>   
>> and if so, does anyone know off-hand
>> which optimizations do this?
>>     
>
> The optimizer does not emit any statistics here. You can search
> various transformation passes' code to see whether they are handling
> DbgInfoIntrinsics or not. Or may be I misunderstood your question ?
>   
Thanks for the information.

You've understood me correctly.  I was just hoping that somebody could 
save me the trouble of looking at all the optimizations to see which 
ones zap debug information.

>> 2) I believe a new debug annotation design is being implemented in
>> mainline LLVM for the 2.7 release.  What is the current status of this
>> work?  Does it already yield more accurate debug information than LLVM 2.6?
>>     
>
> It is still a work in progress. However, now it yields better scoping
> information when clang FE is used to generate debug info.
>   
Does the debug facilities in LLVM TOT, at present, maintain information 
better than LLVM 2.6 (i.e., if a front-end puts the debug information 
in, will the optimizations not take it out)?  Does the information that 
the llvm-gcc front-end adds comparable to what llvm-gcc in LLVM 2.6 does?

The problem that I'm having is that the SAFECode debug tool uses LLVM 
debug information to print out nice error messages saying, "Your buffer 
overflow is at line <x> in source file <file.c>."  Before transforms 
started removing debug information, my tool would print out source 
line/file info that was acceptably accurate.  After the change, it 
started printing out horribly wrong information (e.g., giving the source 
and line number of some inlined function called by the function that 
actually generated the memory error).

I'm not so concerned with debug information being more accurate 
(although I like that, too).  I'm more concerned with how well existing 
debug information is retained during optimizations.

-- John T.

> -
> Devang
>