[llvm-bugs] [Bug 43005] New: incorrect unwind info for split-stack prologue cold block

[via llvm-bugs]

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

            Bug ID: 43005
           Summary: incorrect unwind info for split-stack prologue cold
                    block
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: thanm at google.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

Created attachment 22378
  --> https://bugs.llvm.org/attachment.cgi?id=22378&action=edit
compressed tar file with testcase src and makefile

The unwind info being generated by LLVM for the split-stack cold-path prolog
code appears to be incorrect -- this can trigger problems with the unwinder if
we happen to get a signal (ex: SIGPROF) while executing this code.  GCC does
not have this same problem.

Here is an example to illustrate (will attach tar file with sources, etc):

$ cat test.c

  typedef unsigned long long ull;
  extern ull g(ull a1, ull a2, ull a3, ull a4, char *);
  ull f(ull a1, ull a2, ull a3, ull a4)
  {
    char blob[1024*1024];
    if (a1 != 0)
      return f(a1-1, a2, a3, a4);
    return g(a1, a2, a3, a4, &blob[0]) +
        g(a1^a2, a2-a1, a3<<1, a4>>2, &blob[0]) +
        g(a4^a1, a3-a2, a4<<3, a3>>a4, &blob[0]);
  }

When this code is compiled with "clang -O -c -fsplit-stack" we wind up with
this code:

0000000000000000 <f>:
   0:   lea    -0x100038(%rsp),%r11
   8:   cmp    %fs:0x70,%r11
  11:   jbe    b9 <f+0xb9>
  17:   push   %rbp
  18:   push   %r15
  1a:   push   %r14
  1c:   push   %r13
  1e:   push   %r12
  20:   push   %rbx
  21:   sub    $0x100008,%rsp
  28:   mov    %rcx,%r14
  ... body of f ...
  b3:   pop    %r14
  b5:   pop    %r15
  b7:   pop    %rbp
  b8:   retq   
  b9:   movabs $0x100038,%r10
  c3:   movabs $0x0,%r11
  cd:   callq  __morestack <f+0xd2>
  d2:   retq   
  d3:   jmpq   17 <f+0x17>


The code starting at offset 0xb9 is the "cold path" for split stack; it calls
the __morestack routine to allocate a new segment, then branches back to 0x17
(the main part of the prolog). The unwind info for this function looks like:

$ readelf --debug-dump=frames=interp test.o

....
   LOC           CFA      rbx   rbp   r12   r13   r14   r15   ra    
0000000000000000 rsp+8    u     u     u     u     u     u     c-8   
0000000000000018 rsp+16   u     u     u     u     u     u     c-8   
000000000000001a rsp+24   u     u     u     u     u     u     c-8   
000000000000001c rsp+32   u     u     u     u     u     u     c-8   
000000000000001e rsp+40   u     u     u     u     u     u     c-8   
0000000000000020 rsp+48   u     u     u     u     u     u     c-8   
0000000000000021 rsp+56   u     u     u     u     u     u     c-8   
0000000000000028 rsp+1048640 c-56  c-16  c-48  c-40  c-32  c-24  c-8   
00000000000000ae rsp+56   c-56  c-16  c-48  c-40  c-32  c-24  c-8   
00000000000000af rsp+48   c-56  c-16  c-48  c-40  c-32  c-24  c-8   
00000000000000b1 rsp+40   c-56  c-16  c-48  c-40  c-32  c-24  c-8   
00000000000000b3 rsp+32   c-56  c-16  c-48  c-40  c-32  c-24  c-8   
00000000000000b5 rsp+24   c-56  c-16  c-48  c-40  c-32  c-24  c-8   
00000000000000b7 rsp+16   c-56  c-16  c-48  c-40  c-32  c-24  c-8   
00000000000000b8 rsp+8    c-56  c-16  c-48  c-40  c-32  c-24  c-8

Note the last line: this is showing a correct location for CFA, but rbx is
incorrect -- showing c-56 when in fact the right value would be "u", since at
this poin the execution we haven't run any of the prolog code yet (save rbp
etc, update sp, and so on).

A corrected row would look like

00000000000000b8 rsp+8    u     u     u     u     u     u     c-8   

See also related change https://reviews.llvm.org/D66013

-- 
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/20190815/ed2e91aa/attachment-0001.html>