[llvm] [DebugInfo] Don't set prologue_end behind line-zero call insts (PR #156850)

[Jeremy Morse via llvm-commits]

================
@@ -0,0 +1,127 @@
+# RUN: llc %s -start-after=livedebugvalues -o - -filetype=obj | llvm-dwarfdump - --debug-line | FileCheck %s
+#
+## Original code, compiled clang -O2 -g -c
+## 
+## void ext();
+## int main(int argc, char **argv) {
+##   if (argc == 1)
+##     ext();
+##   else
+##     ext();
+##    return 0;
+## }
+## 
+## In the code sequence above, the call to ext is given line zero during
+## optimisation, because the code is duplicated down all function paths thus
+## gets merged. We get something like this as the output:
+##
+##   0:   50                      push   %rax
+##   1:   31 c0                   xor    %eax,%eax
+##   3:   e8 00 00 00 00          call   8 <main+0x8>
+##   4: R_X86_64_PLT32       ext-0x4
+##   8:   31 c0                   xor    %eax,%eax
+##   a:   59                      pop    %rcx
+##   b:   c3                      ret
+##
+## And we could choose to set prologue_end on address 8, the clearing of the
+## return register, because it's the first "real" instruction that isn't line
+## zero. But this then causes debuggers to skip over the call instruction when
+## entering the function, which is catastrophic.
+##
+## Instead: we force the xor at address 1 to have a source location (the
+## function scope line number), and put a prologue_end there. While it's a
+## setup instruction, it's better to have a prologue_end that's still slightly
+## in the prologue than to step over the call. This gives consumers the
+## opportunity to recognise "this is a crazy function" and act accordingly.
+##
+## Check lines: the first entry is the start-of-function scope line, the second
+## entry is the prologue_end on the xor, while the third is the zero-line-number
+## call instruction.
+#
+# CHECK:       2      0      0   0             0       0  is_stmt
+# CHECK-NEXT:  2      0      0   0             0       0  is_stmt prologue_end
+# CHECK-NEXT:  0      0      0   0             0       0
----------------
jmorse wrote:

I've switched to examining the textual output, which has the upside of not printing hex, but still having the meaning of the .loc lines and their flags in the context of the instructions.

https://github.com/llvm/llvm-project/pull/156850