[DebugInfo] always-inlining of allocas gives wrong source-location attribution to stack-protection

[jmorse]

The test at llvm/test/DebugInfo/Generic/debug-info-always-inline.ll has bitrotted to death, to the extent LLVM appears to have regressed without us noticing. The test text states that it's looking for:

• inlined allocas getting placed in the entry block of the caller,
• with a source-location associated with the callee,
• that then leaks onto stack-protection instructions inserted during codegen

With the result that a source location from the callee function can appear at the start of a function, before control flow has actually reached that point. This is a scenario where (as per the HowToUpdateDebugInfo document) we should drop the source location, because the instruction moves out of its original block (inlining notwithstanding) and isn't merged with other instructions.

Right now, the test in question only checks that the inlined instructions exist with no debug-info; it doesn't check that other debug-info is preserved. The test prints on stderr:

  warning: ignoring debug info with an invalid version (1)

i.e., all the debug-info is being dropped, so the test passes vacuously. Various other bits of debug-info here are broken as it's such an old test.

After stripping debug-info, attaching more with debugify, I've got the attached, which if you run:

  opt out2.ll  -o - -S --passes=always-inline | llc -o out.o -filetype=obj -

targetting x86_64, produces an object file that appears to represent the error the test is testing for. I'm using LLVM based on 42ee758. The "main" function prologue:

0000000000000050 <main>:
  50:   48 83 ec 48             sub    $0x48,%rsp
  54:   64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
  5b:   00 00
  5d:   48 89 44 24 40          mov    %rax,0x40(%rsp)

The line-table:

Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000050      7      0      1   0             0  is_stmt
0x0000000000000054      1      1      1   0             0  is_stmt prologue_end
0x0000000000000062      9      1      1   0             0  is_stmt

i.e., the stack-protection load from %fs gets line-number one, which belongs to the inlinee function. Thus, when you enter the main function, you immediately step into the inlinee.

I've only run into this because the autoupgrading of the ancient dbg.declares breaks RemoveDIs autoupgrade in rare circumstances; I've got too much on my plate to fix immediately.

More modern reproducer: out2.ll.txt

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Jeremy Morse (jmorse)

The test at `llvm/test/DebugInfo/Generic/debug-info-always-inline.ll` has bitrotted to death, to the extent LLVM appears to have regressed without us noticing. The test text states that it's looking for: * inlined allocas getting placed in the entry block of the caller, * with a source-location associated with the callee, * that then leaks onto stack-protection instructions inserted during codegen

With the result that a source location from the callee function can appear at the start of a function, before control flow has actually reached that point. This is a scenario where (as per the HowToUpdateDebugInfo document) we should drop the source location, because the instruction moves out of its original block (inlining notwithstanding) and isn't merged with other instructions.

Right now, the test in question only checks that the inlined instructions exist with no debug-info; it doesn't check that other debug-info is preserved. The test prints on stderr:

  warning: ignoring debug info with an invalid version (1)

i.e., all the debug-info is being dropped, so the test passes vacuously. Various other bits of debug-info here are broken as it's such an old test.

After stripping debug-info, attaching more with debugify, I've got the attached, which if you run:

  opt out2.ll  -o - -S --passes=always-inline | llc -o out.o -filetype=obj -

targetting x86_64, produces an object file that appears to represent the error the test is testing for. I'm using LLVM based on 42ee758. The "main" function prologue:

0000000000000050 <main>:
  50:   48 83 ec 48             sub    $0x48,%rsp
  54:   64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
  5b:   00 00
  5d:   48 89 44 24 40          mov    %rax,0x40(%rsp)

The line-table:

Address            Line   Column File   ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000050      7      0      1   0             0  is_stmt
0x0000000000000054      1      1      1   0             0  is_stmt prologue_end
0x0000000000000062      9      1      1   0             0  is_stmt

i.e., the stack-protection load from %fs gets line-number one, which belongs to the inlinee function. Thus, when you enter the main function, you immediately step into the inlinee.

I've only run into this because the autoupgrading of the ancient dbg.declares breaks RemoveDIs autoupgrade in rare circumstances; I've got too much on my plate to fix immediately.

More modern reproducer: out2.ll.txt