[LLVMbugs] [Bug 16660] New: miscompilation with -fPIC, ASAN and #pragma GCC visibility push(hidden)

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Jul 19 04:56:55 PDT 2013


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

            Bug ID: 16660
           Summary: miscompilation with -fPIC, ASAN and #pragma GCC
                    visibility push(hidden)
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: kcc at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10899
  --> http://llvm.org/bugs/attachment.cgi?id=10899&action=edit
x.ll

[Initially reported as a crash in asan-ified Firefox: 
https://code.google.com/p/address-sanitizer/issues/detail?id=204]
x86_64 linux, r186656

Minimized test case: 

==> x.cc <==
#pragma GCC visibility push(hidden)
extern __thread int x;
int foo() {
  return x;
}

==> y.cc <==
__thread int x;

% clang -O -fsanitize=address x.cc -fPIC -S -o - -emit-llvm | less
define hidden i32 @_Z3foov() #0 {
entry:
  %0 = load i8* inttoptr (i64 add (i64 lshr (i64 ptrtoint (i32* @x to i64), i64
3), i64 2147450880) to i8*)
  %1 = icmp ne i8 %0, 0
  br i1 %1, label %2, label %5

; <label>:2                                       ; preds = %entry
  %3 = icmp sge i8 trunc (i64 add (i64 and (i64 ptrtoint (i32* @x to i64), i64
7), i64 3) to i8), %0
  br i1 %3, label %4, label %5

; <label>:4                                       ; preds = %2
  call void @__asan_report_load4(i64 ptrtoint (i32* @x to i64))
  call void asm sideeffect "", ""()
  unreachable

; <label>:5                                       ; preds = %2, %entry
  %6 = load i32* @x, align 4, !tbaa !0
  ret i32 %6
}



% clang -O -fsanitize=address x.cc y.cc  -fPIC -shared -o x.so ; objdump -d
x.so | less -pfoo
00000000000007b0 <_Z3foov>:
 7b0:   50                      push   %rax
 7b1:   48 8d 3d f8 07 20 00    lea    0x2007f8(%rip),%rdi        # 200fb0
<_DYNAMIC+0x1b0>
 7b8:   e8 f3 fe ff ff          callq  6b0 <__tls_get_addr at plt>
 7bd:   48 89 c1                mov    %rax,%rcx
 7c0:   48 8d 89 00 00 00 00    lea    0x0(%rcx),%rcx
 7c7:   48 c1 e9 03             shr    $0x3,%rcx
 7cb:   8a 91 00 80 ff 7f       mov    0x7fff8000(%rcx),%dl
 7d1:   84 d2                   test   %dl,%dl
 7d3:   74 1a                   je     7ef <_Z3foov+0x3f>
 7d5:   48 89 c1                mov    %rax,%rcx
 7d8:   48 be c4 0d 20 00 00    movabs $0x200dc4,%rsi       
<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ???????????
 7df:   00 00 00 
 7e2:   01 ce                   add    %ecx,%esi
 7e4:   83 e6 07                and    $0x7,%esi
 7e7:   83 c6 03                add    $0x3,%esi
 7ea:   40 38 d6                cmp    %dl,%sil
 7ed:   7d 08                   jge    7f7 <_Z3foov+0x47>
 7ef:   8b 80 00 00 00 00       mov    0x0(%rax),%eax
 7f5:   5a                      pop    %rdx
 7f6:   c3                      retq   
 7f7:   48 8d 80 00 00 00 00    lea    0x0(%rax),%rax
 7fe:   48 89 c7                mov    %rax,%rdi
 801:   e8 9a fe ff ff          callq  6a0 <__asan_report_load4 at plt>
 806:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)


Here we have a TLS object x, which addressed is used 3 times (one time from the
original code and two times in the asan-added instrumentation).
The LLVM IR looks sane to me, but the assembly is bogus, there is some extra
instruction movabs $0x200dc4,%rsi


San someone help me investigate why does the CG produce this extra instruction? 

Just in case, attaching the .ll files: 
% llc -relocation-model=pic  x.ll; llc -relocation-model=pic y.ll ; gcc -shared
-fPIC x.s y.s -o x.so; objdump -d x.so | less -pfoo

-- 
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/20130719/35b2b02b/attachment.html>


More information about the llvm-bugs mailing list