[LLVMdev] Bug with debug information generation?

[Eric Christopher]

Heh. I was just responding to it. A bug report isn't a bad thing. It's likely the backend losing the location if it's wrong.

-eric

On Apr 26, 2012, at 2:28 PM, Matt Pharr <matt.pharr at gmail.com> wrote:

> 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
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev