<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Filed as <a href="http://llvm.org/bugs/show_bug.cgi?id=12678">http://llvm.org/bugs/show_bug.cgi?id=12678</a>.<div><br><div><div>On Apr 23, 2012, at 2:03 PM, <a href="mailto:llvmdev-request@cs.uiuc.edu">llvmdev-request@cs.uiuc.edu</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I'm seeing some strange behavior with generating debugging information from a simple program. (LLVM top of tree, minus a couple of days.)<br><br>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.<br><br>Given this simple function in the file bug.cpp:<br><br>float foo() {<br> float r = 0;<br> r = 1;<br> ++r;<br> r *= 3;<br> return r;<br>}<br><br>and then a separate main.cpp:<br><br>extern float foo();<br><br>int main() {<br> foo();<br>}<br><br>If we compile and link an executable:<br><br>% clang -c bug.cpp -g -emit-llvm -o bug.bc<br>% llvm-dis bug.bc<br>% llc bug.ll -o bug.o -filetype=obj<br>% clang -g bug.o main.cpp<br><br>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)).<br><br>However, if I edit bug.ll and add the single line:<br><br> %internal_mask_memory = alloca <8 x i32><br><br>Right after the entry: label and then recompile and run gdb, then when stepping through "foo", the value "0" is always printed for "r".<br><br>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.<br><br>I'd be delighted to hear any suggestions or pointers!<br><br>Thanks,<br>-matt<br><br></blockquote></div><br></div></body></html>