[llvm-bugs] [Bug 46813] New: Wrong compact unwind information for functions using stack probes

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Jul 22 14:07:58 PDT 2020


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

            Bug ID: 46813
           Summary: Wrong compact unwind information for functions using
                    stack probes
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: alex at crichton.co
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

In rust-lang/rust we've for the longest time enabled frame pointers on our
macOS targets, but we're looking at that again recently and trying to figure
out why we're still doing this. An attempt to disable frame pointers, however,
led to segfaults during unwinding. We investigated this a bit and came up on
this issue.

The issue here we found is that the compact unwind information for a function
with a large stack frame is incorrect if the "probe-stack" attribute is used.
Namely this IR:



target triple = "x86_64-apple-macosx10.7.0"

define void @foo() #0 {
start:
  %_huge_stack = alloca [1024 x i64], align 8
  call void @bar()
  ret void
}

declare void @bar()

attributes #0 = { uwtable "probe-stack"="__probestack" }




when compiled yields:


    $ llc unwind.ll -o foo.o -filetype=obj
    $ llvm-objdump foo.o -uS
    foo.o:      file format mach-o 64-bit x86-64


    Disassembly of section __TEXT,__text:

    0000000000000000 <_foo>:
    ./build/bin/llvm-objdump: warning: 'foo.o': failed to parse debug
information for foo.o
           0: b8 08 20 00 00                    movl    $8200, %eax
           5: e8 00 00 00 00                    callq   0xa <_foo+0xa>
           a: 48 29 c4                          subq    %rax, %rsp
           d: e8 00 00 00 00                    callq   0x12 <_foo+0x12>
          12: 48 81 c4 08 20 00 00              addq    $8200, %rsp
          19: c3                                retq
    Unwind info:

    Contents of __compact_unwind section:
      Entry at offset 0x0:
        start:                0x0 _foo
        length:               0x1a
        compact encoding:     0x03032000


Here the compact unwind information for `foo` is 0x03032000, where the tag
(0x3000000) indicates `UNWIND_X86_64_MODE_STACK_IND`, which according to online
documentation says:

// UNWIND_X86_64_MODE_STACK_IND:
//    A "frameless" (RBP not used as frame pointer) function large constant 
//    stack size.  This case is like the previous, except the stack size is too
//    large to encode in the compact unwind encoding.  Instead it requires that 
//    the function contains "subq $nnnnnnnn,RSP" in its prolog.  The compact 
//    encoding contains the offset to the nnnnnnnn value in the function in
//    UNWIND_X86_64_FRAMELESS_STACK_SIZE.  


For this function, however, the `subq` instruction doesn't exist with a
constant, but rather `%rax` which comes from `__probestack`

-- 
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/20200722/3858aa72/attachment.html>


More information about the llvm-bugs mailing list