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
