[LLVMdev] Bug with debug information generation?

[Matt Pharr]

Filed as http://llvm.org/bugs/show_bug.cgi?id=12678.

On Apr 23, 2012, at 2:03 PM, llvmdev-request at cs.uiuc.edu wrote:

> I'm seeing some strange behavior with generating debugging information from a simple program.  (LLVM top of tree, minus a couple of days.)
> 
> I suspect that there is a bug in LLVM, but thought I'd check in here to see if perhaps I'm doing something wrong or misunderstanding something.  In short, if I add a single (totally unused) alloca of an <8 x i32> to a function, then the debugger prints garbage for the values of other variables in the function.  I'm seeing this with the ispc compiler, but just to eliminate that as a factor, here is an example of what I'm seeing via clang.
> 
> Given this simple function in the file bug.cpp:
> 
> float foo() {
>    float r = 0;
>    r = 1;
>    ++r;
>    r *= 3;
>    return r;
> }
> 
> and then a separate main.cpp:
> 
> extern float foo();
> 
> int main() {
>    foo();
> }
> 
> If we compile and link an executable:
> 
> % clang -c bug.cpp -g -emit-llvm -o bug.bc
> % llvm-dis bug.bc
> % llc bug.ll -o bug.o -filetype=obj
> % clang -g bug.o main.cpp
> 
> Then debugging works fine and the value of r can be printed correctly if one steps through the function (GNU gdb 6.3.50-20050815 (Apple version gdb-1708)).
> 
> However, if I edit bug.ll and add the single line:
> 
>  %internal_mask_memory = alloca <8 x i32>
> 
> Right after the entry: label and then recompile and run gdb, then when stepping through "foo", the value "0" is always printed for "r".
> 
> One other piece of possibly relevant information is that if I run "dwarfdump" on both of the corresponding object files, the output is almost entirely the same, though in the working case, it had AT_frame_base( rsp ), while the broken case had AT_frame_base( rbp ).  Some of the PC extents are different, but in ways that look reasonable. For the location of "r" in the working case, it has AT_location( fbreg -4 ), with AT_location( fbreg +28 ) in the broken case.  These locations both seem correct, based on an eyeballing of the assembly output, so there's nothing obviously wrong there, either.
> 
> I'd be delighted to hear any suggestions or pointers!
> 
> Thanks,
> -matt
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120426/94771990/attachment.html>