[llvm-bugs] [Bug 49600] New: probe-stack=inline-asm will produce invalid uwtables

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49600

            Bug ID: 49600
           Summary: probe-stack=inline-asm will produce invalid uwtables
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: simonas+llvm.org at kazlauskas.me
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, pengfei.wang at intel.com,
                    spatel+llvm at rotateright.com

Given a function as such

; RUN: llc < %s
define void @big_stack() "probe-stack"="inline-asm" uwtable {
start:
  %_two_page_stack = alloca [8192 x i8], align 1
  ret void
}

the following assembly will be generated:

big_stack:
        .cfi_startproc
        subq    $4096, %rsp
        movq    $0, (%rsp)
        subq    $3968, %rsp
        .cfi_def_cfa_offset 8072
        addq    $8064, %rsp
        .cfi_def_cfa_offset 8
        retq


Here the unwind tables are not accurate while stack probing is ongoing – the
`rsp` is adjusted, but not the `cfa_offsets`. And so attempts to obtain a stack
trace will fail if the current instruction is somewhere in between the
instructions implementing the stack probing.

This also occurs with the non-unrolled implementation of the stack probing:

; RUN: llc < %s
define void @big_stack() "probe-stack"="inline-asm" uwtable {
start:
  %_two_page_stack = alloca [64000 x i8], align 1
  ret void
}

--->

big_stack:
        .cfi_startproc
        movq    %rsp, %r11
        subq    $61440, %r11
.LBB0_1:
        subq    $4096, %rsp
        movq    $0, (%rsp)
        cmpq    %r11, %rsp
        jne     .LBB0_1
        subq    $2432, %rsp
        .cfi_def_cfa_offset 63880
        addq    $63872, %rsp
        .cfi_def_cfa_offset 8
        retq

however in the loop case the solution needs to involve allocation of a separate
register as insertion of `.cfi` directives in a loop won't help in any way.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210316/dfac1a34/attachment.html>