It is possible to have successive machine instructions at the MIR level which each have a debug location of line 0, but for different files, as in the example below (edited for readability):
bb.8.handler.type_mismatch12:
liveins: $rsi
$edi = MOV32ri @6, implicit-def $rdi, debug-location !DILocation(line: 0, scope: !52, inlinedAt: !55) /* b.c:0 inlined in a.c */
bb.9.cleanup:
liveins: $rdi, $rsi
CALL64pcrel32 target-flags(x86-plt) @__ubsan_handle_type_mismatch_v1, /* ... */, debug-location !DILocation(line: 0, scope: !33) /* a.c:0 */At the moment however, LLVM DWARF emission skips the second line 0 without considering the changed file:
|
// We have an explicit location, different from the previous location. |
|
// Don't repeat a line-0 record, but otherwise emit the new location. |
|
// (The new location might be an explicit line 0, which we do emit.) |
|
if (DL.getLine() == 0 && LastAsmLine == 0) |
|
return; |
This means the file change is lost. A debugger's backtrace and disassembly views would thus show the wrong file for the second instruction. This also affects other analysis tools (e.g. sanitisers like UBSan in the example above) that wish to report a stack trace for failure locations, as they will currently cite the wrong file.
It is possible to have successive machine instructions at the MIR level which each have a debug location of line 0, but for different files, as in the example below (edited for readability):
At the moment however, LLVM DWARF emission skips the second line 0 without considering the changed file:
llvm-project/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Lines 2267 to 2271 in 10f8499
This means the file change is lost. A debugger's backtrace and disassembly views would thus show the wrong file for the second instruction. This also affects other analysis tools (e.g. sanitisers like UBSan in the example above) that wish to report a stack trace for failure locations, as they will currently cite the wrong file.