[llvm-bugs] [Bug 25614] New: Shrink-wrapping breaks frameless indirect compact unwind emission

[via llvm-bugs]

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

            Bug ID: 25614
           Summary: Shrink-wrapping breaks frameless indirect compact
                    unwind emission
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: cdavis5x at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The compact unwind emitters (at least, the x86 one) currently assume that the
prologue is at the beginning of the function. That way, for a frameless
function with a large stack allocation, it can figure the offset of the stack
allocation amount based solely on the CFI.

Shrink-wrapping breaks this assumption, because now the prologue may no longer
be at the beginning of the function. But, for a frameless function with a large
stack allocation, the compact unwind emitter stores the offset of the stack
allocation amount relative to the prologue, not the beginning of the function.
Thus, when the unwinder reads the unwind information for this function, it will
happily use the offset given in the unwind info... and get a bogus result,
leading to a crash in the unwinder... or worse, no crash and a bad
backtrace/unwind.

This assembly test case demonstrates the problem:

        .section        __TEXT,__text,regular,pure_instructions
        .globl  _test2
_test2:                                 ## @test2
        .cfi_startproc
## BB#0:                                ## %prologue
        movzbl  _guard(%rip), %eax
        andl    $1, %eax
        cmpl    $1, %eax
        jne     LBB0_2
## BB#1:
        retq
LBB0_2:                                 ## %.0.entry
        subq    $3232, %rsp             ## imm = 0xca0
Ltmp20:
        .cfi_def_cfa_offset 3240
        callq   _foo
        addq    $3232, %rsp             ## imm = 0xca0
        retq
        .cfi_endproc

.subsections_via_symbols

Note the code preceding the prologue, checking to see if the function should be
executed. We should produce a compact encoding of 0x03132000, but we wind up
producing 0x03032000 (i.e. stack allocation offset is 3 when it should be 19).

Unfortunately, at this point, the information we need (i.e. the offset of the
prologue) is missing. We certainly won't have this information for raw
assembly.

-- 
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/20151123/dd73e7ca/attachment.html>