[PATCH] D78438: [ELF] Fix "TLS attribute mismatch" false positives for STT_NOTYPE undefined symbols

[Fangrui Song via Phabricator via llvm-commits]

MaskRay updated this revision to Diff 258907.
MaskRay retitled this revision from "[ELF] Temporarily delete "TLS attribute mismatch" diagnostics" to "[ELF] Fix "TLS attribute mismatch" false positives for STT_NOTYPE undefined symbols".
MaskRay edited the summary of this revision.
MaskRay added a comment.

After more thoughts, I think we should retain the diagnostic but add an exception that STT_NOTYPE undefined symbol should be allowed to be replaced.

The existing wording is not ideal because TLS relocations should support some non-TLS symbols, e.g. STT_SECTION, and probably also STT_NOTYPE undefined.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78438/new/

https://reviews.llvm.org/D78438

Files:
  lld/ELF/Symbols.h
  lld/test/ELF/tls-mismatch.s


Index: lld/test/ELF/tls-mismatch.s
===================================================================
--- lld/test/ELF/tls-mismatch.s
+++ lld/test/ELF/tls-mismatch.s
@@ -12,8 +12,10 @@
 ## We fail to flag the swapped case.
 # RUN: ld.lld %t.o %t2.o -o /dev/null
 
+## We fail to flag the STT_NOTYPE reference. This usually happens with hand-written
+## assembly because compiler-generated code properly sets symbol types.
 # RUN: echo 'movq tls1,%rax' | llvm-mc -filetype=obj -triple=x86_64 - -o %t3.o
-# RUN: not ld.lld %t3.o %t.o -o /dev/null 2>&1 | FileCheck %s
+# RUN: ld.lld %t3.o %t.o -o /dev/null
 
 ## Overriding a TLS definition with a non-TLS definition does not make sense.
 # RUN: not ld.lld --defsym tls1=42 %t.o -o /dev/null 2>&1 | FileCheck %s
@@ -21,11 +23,13 @@
 ## Part of PR36049: This should probably be allowed.
 # RUN: not ld.lld --defsym tls1=tls2 %t.o -o /dev/null 2>&1 | FileCheck %s
 
+## An undefined symbol in module-level inline assembly of a bitcode file
+## is considered STT_NOTYPE. We should not error.
 # RUN: echo 'target triple = "x86_64-pc-linux-gnu" \
 # RUN:   target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" \
 # RUN:   module asm "movq tls1 at GOTTPOFF(%rip), %rax"' | llvm-as - -o %t.bc
 # RUN: ld.lld %t.o %t.bc -o /dev/null
-# RUN: not ld.lld %t.bc %t.o -o /dev/null 2>&1 | FileCheck %s
+# RUN: ld.lld %t.bc %t.o -o /dev/null
 
 # CHECK: error: TLS attribute mismatch: tls1
 
Index: lld/ELF/Symbols.h
===================================================================
--- lld/ELF/Symbols.h
+++ lld/ELF/Symbols.h
@@ -517,13 +517,16 @@
 void Symbol::replace(const Symbol &newSym) {
   using llvm::ELF::STT_TLS;
 
-  // Symbols representing thread-local variables must be referenced by
-  // TLS-aware relocations, and non-TLS symbols must be reference by
-  // non-TLS relocations, so there's a clear distinction between TLS
-  // and non-TLS symbols. It is an error if the same symbol is defined
-  // as a TLS symbol in one file and as a non-TLS symbol in other file.
-  if (symbolKind != PlaceholderKind && !isLazy() && !newSym.isLazy() &&
-      (type == STT_TLS) != (newSym.type == STT_TLS))
+  // st_value of STT_TLS represents the assigned offset, not the actual address
+  // which is used by STT_FUNC and STT_OBJECT. STT_TLS symbols can only be
+  // referenced by special TLS relocations. It is usually an error if a STT_TLS
+  // symbol is replaced by a non-STT_TLS symbol, vice versa. symbol in other
+  // file. There are two exceptions: (a) a STT_NOTYPE lazy/undefined symbol can
+  // be replaced by a STT_TLS symbol, (b) a STT_TLS undefined symbol can be
+  // replaced by a STT_NOTYPE lazy symbol.
+  if (symbolKind != PlaceholderKind && !newSym.isLazy() &&
+      (type == STT_TLS) != (newSym.type == STT_TLS) &&
+      type != llvm::ELF::STT_NOTYPE)
     error("TLS attribute mismatch: " + toString(*this) + "\n>>> defined in " +
           toString(newSym.file) + "\n>>> defined in " + toString(file));
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D78438.258907.patch
Type: text/x-patch
Size: 2978 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200421/da2ec2c3/attachment.bin>