Created attachment 18046 [details] IR with bad codegen When there are 2 consecutive basic blocks (even if they don't branch to one another at all) on the same DI code line, no .loc debuginfo is emitted on the second basic block, so breakpoints into it get missed and step-over jumps over it ## Meta $ dpkg -S `which llc-3.9` llvm-3.9: /usr/bin/llc-3.9 $ dpkg-query -W -f='${Version}\n' llvm-3.9 1:3.9.1-4 ## STR & actual result $ llc-3.9 di.ll -relocation-model=pic $ gcc di.s $ gdb ./a.out ... (gdb) b di.rs:3 Breakpoint 1 at 0x677: file /cache/di.rs, line 3. (gdb) r Starting program: /cache/a.out [Inferior 1 (process 16580) exited with code 0160] (gdb) q ; How was my breakpoint skipped? ## Expected Result Both calls to `bar` are in line 3, and the second call is run, so the breakpoint should get hit (equivalently, stepping through using `next` should go through lines 2->3->4).
For reference, heart of sample code: define void @main(i64, i8**) !dbg !366 { entry-block: %cmp = icmp ne i64 %0, 1, !dbg !1002 br i1 %cmp, label %bb1, label %bb2, !dbg !1002 bb1: call void @bar(), !dbg !1003 br label %bb1, !dbg !1003 bb2: call void @bar(), !dbg !1003 ret void, !dbg !1004 }
If you enable column information, that might help. I believe it's `-gcolumn-info`.
Shooting from the hip: Fixing this fully would probably involve tracking "is stmt" from the frontend (there are a few issues that this might fix). Probably by adding a stmt scope node or the like. Alternatively/short-term it might be possible to get somewhat better behavior by putting a new line entry at the start of every basic block, even if it's the same location as the previous one. This might cause too much breaking, though - "x ? f1() : f1()" would then probably break for x and the call to f1 (whichever one executed).