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
>