[llvm-bugs] [Bug 35140] New: MIPS: Thread local variable not flagged as thread local in object file

[via llvm-bugs]

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

            Bug ID: 35140
           Summary: MIPS: Thread local variable not flagged as thread
                    local in object file
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: MIPS
          Assignee: unassignedbugs at nondot.org
          Reporter: alex at crichton.co
                CC: llvm-bugs at lists.llvm.org

We've been getting weird linkage errors in rust-lang/rust [1] which I believe
we've minimized to this IR:



@foo = external hidden thread_local global i32

define i32 @bar() {
  %a = load i32, i32* @foo
  ret i32 %a
}



I don't personally know a lot about MIPS unfortunately, but I think this may
show the problem:


$ llc foo.ll -filetype=obj -o foo.o -mtriple=mipsel-unknown-linux-gnu
-relocation-model=pic
$ readelf -Ws foo.o

Symbol table '.symtab' contains 7 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS foo.ll
     2: 00000000     0 SECTION LOCAL  DEFAULT    2
     3: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __tls_get_addr
     4: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND _gp_disp
     5: 00000000    56 FUNC    GLOBAL DEFAULT    2 bar
     6: 00000000     0 NOTYPE  GLOBAL HIDDEN   UND foo



Note that the import of `foo` under "Type" says "NOTYPE", whereas normally TLS
variables have "TLS" mentioned there. Also note that if `hidden` is removed
from the IR or the `-relocation-model=pic` argument is dropped then the "Type"
listed is indeed "TLS". 

Is this perhaps expected behavior and I'm barking up the wrong tree? I tried
compiling the equivalent C code with gcc to see what it output:


$ cat foo.c
extern __thread int foo __attribute__((visibility("hidden")));

int bar() {
        return foo;
}
$ mipsel-linux-gnu-gcc foo.c -c && mipsel-linux-gnu-readelf -Ws foo.o

Symbol table '.symtab' contains 14 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS foo.c
     2: 00000000     0 SECTION LOCAL  DEFAULT    1
     3: 00000000     0 SECTION LOCAL  DEFAULT    3
     4: 00000000     0 SECTION LOCAL  DEFAULT    4
     5: 00000000     0 SECTION LOCAL  DEFAULT    9
     6: 00000000     0 SECTION LOCAL  DEFAULT    5
     7: 00000000     0 SECTION LOCAL  DEFAULT    6
     8: 00000000     0 SECTION LOCAL  DEFAULT    7
     9: 00000000     0 SECTION LOCAL  DEFAULT   10
    10: 00000000     0 SECTION LOCAL  DEFAULT   11
    11: 00000000    60 FUNC    GLOBAL DEFAULT    1 bar
    12: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __gnu_local_gp
    13: 00000000     0 TLS     GLOBAL HIDDEN   UND foo


Note that the reference to `foo` is flagged as TLS and HIDDEN, so that's what
caused me to think that this may be an accidental bug in LLVM's codegen
perhaps?


[1]: https://travis-ci.org/rust-lang/rust/jobs/293501043

-- 
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/20171030/8c6b4ace/attachment.html>