[LLVMbugs] [Bug 11080] New: Jump to incorrect address (off by 4 bytes) is being generated [x86, OSX]

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=11080

           Summary: Jump to incorrect address (off by 4 bytes) is being
                    generated [x86, OSX]
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7413)
 --> (http://llvm.org/bugs/attachment.cgi?id=7413)
bitcode

If the attached test case is compiled and run, it generates a seg fault.  From
the debugging I've done, it seems to be due to a call instruction being emitted
with an incorrect offset.  (Further details in the following.)

I've only been able to reproduce this on OSX (and not Linux, for example), but
don't know if this means that it's an OSX-specific issue, or if it's just
happenstance that it doesn't happen on Linux.

% llc x.ll -filetype=obj -o x.o && clang -g x.cpp x.o && ./a.out
[1]    70823 segmentation fault  ./a.out

However, if 'private' qualifier from the @__do_print() function at the top of
x.ll is removed, it produces the correct output (basically, printing the two
values passed to it via the %args array parameter.)

% llc x.ll -filetype=obj -o x.o && clang -g x.cpp x.o && ./a.out
yep 2.000000 2.000000

In the case where it's crashing, if I disassemble the _p function in gdb (which
calls __do_print), I get the following:

Dump of assembler code for function p:
0x0000000100000e50 <p+0>:    sub    $0x28,%rsp
0x0000000100000e54 <p+4>:    movss  %xmm1,0x4(%rsp)
0x0000000100000e5a <p+10>:    movss  %xmm0,0xc(%rsp)
0x0000000100000e60 <p+16>:    lea    0xc(%rsp),%rax
0x0000000100000e65 <p+21>:    mov    %rax,0x10(%rsp)
0x0000000100000e6a <p+26>:    movss  %xmm1,0x8(%rsp)
0x0000000100000e70 <p+32>:    lea    0x8(%rsp),%rax
0x0000000100000e75 <p+37>:    mov    %rax,0x18(%rsp)
0x0000000100000e7a <p+42>:    lea    0x7a(%rip),%rdi        # 0x100000efb
<__str2>
0x0000000100000e81 <p+49>:    lea    0x7c(%rip),%rsi        # 0x100000f04
<__str3>
0x0000000100000e88 <p+56>:    lea    0x10(%rsp),%r8
0x0000000100000e8d <p+61>:    mov    $0x4,%edx
0x0000000100000e92 <p+66>:    mov    $0xf,%ecx
0x0000000100000e97 <p+71>:    callq  0x100000d8c <main+252>
0x0000000100000e9c <p+76>:    movss  0x4(%rsp),%xmm0
0x0000000100000ea2 <p+82>:    add    $0x28,%rsp
0x0000000100000ea6 <p+86>:    retq   
End of assembler dump.

(This in general looks like the code I'd expect for this function.)  If I
single-step through these instructions, the problem comes immediately after the
callq.  Disassembling at where it ends up, it turns out that it's jumping to
the pop instruction at the end of the main function, instead of the start of
the __do_print function, which happens to start at 0x0000000100000d90.  It
seems to have jumped 4 bytes too early.

... assembly for main() ... ending with ...
0x0000000100000d8c <main+252>:    pop    %rbp
0x0000000100000d8d <main+253>:    retq   
0x0000000100000d8e <main+254>:    xchg   %ax,%ax
0x0000000100000d90 <main+256>:    push   %rbp
0x0000000100000d91 <main+257>:    push   %r15
... assembly for the rest of __do_print ...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.