[LTO] An interesting case which shows up how we handle common symbols.

The gold plugin logic for common symbols is a little bit convoluted
as the plugin API has not an explicit way to update the alignment.
In gold, then, we need to keep the bitcode symbol @a around because
that's the only way to get the alignment right in the final object.

In lld, this is not true. We already have all the informations we
need about common symbols (size/alignment) so we don't have to
keep the existing symbol and pass it to the mover.

llvm-svn: 267007

1 files changed, 24 insertions, 0 deletions

diff --git a/lld/test/ELF/lto/common2.ll b/lld/test/ELF/lto/common2.ll
new file mode 100644
index 00000000000..04b19259c92
--- /dev/null
+++ b/lld/test/ELF/lto/common2.ll
@@ -0,0 +1,24 @@
+; RUN: llvm-as %s -o %t1.o
+; RUN: ld.lld -m elf_x86_64 %t1.o -o %t -shared -save-temps
+; RUN: llvm-dis < %t.lto.bc | FileCheck %s
+; RUN: llvm-readobj -t %t | FileCheck %s --check-prefix=SHARED
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+@a = common global i8 0, align 8
+
+; Shared library case, we ensure that the bitcode generated file
+; has not the a symbol but is appears in the final shared library
+; produced.
+; CHECK-NOT: @a = common global i8 0, align 8
+
+; SHARED: Symbol {
+; SHARED:   Name: a
+; SHARED-NEXT:   Value: 0x2000
+; SHARED-NEXT:   Size: 1
+; SHARED-NEXT:   Binding: Global
+; SHARED-NEXT:   Type: None
+; SHARED-NEXT:   Other: 0
+; SHARED-NEXT:   Section: .bss
+; SHARED-NEXT: }