llvm dev - Apr 2012 - [LLVMdev] Bug with debug information generation?

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>

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