[lld] 342040b - [lld][ELF][test] Add additional test coverage for LTO
James Henderson via llvm-commits
llvm-commits at lists.llvm.org
Fri Oct 23 01:52:06 PDT 2020
Author: James Henderson
Date: 2020-10-23T09:51:30+01:00
New Revision: 342040bf00743cd401f01667dcf54315c64f09e9
URL: https://github.com/llvm/llvm-project/commit/342040bf00743cd401f01667dcf54315c64f09e9
DIFF: https://github.com/llvm/llvm-project/commit/342040bf00743cd401f01667dcf54315c64f09e9.diff
LOG: [lld][ELF][test] Add additional test coverage for LTO
These are all inspired by existing test coverage we have in an internal
testsuite.
Reviewed by: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D89775
Added:
lld/test/ELF/lto/bitcode-wrapper.ll
lld/test/ELF/lto/non-ascii-filenames.ll
Modified:
lld/test/ELF/lto/common.ll
lld/test/ELF/lto/resolution.ll
Removed:
lld/test/ELF/lto/Inputs/common.s
lld/test/ELF/lto/Inputs/resolution.s
################################################################################
diff --git a/lld/test/ELF/lto/Inputs/common.s b/lld/test/ELF/lto/Inputs/common.s
deleted file mode 100644
index e2cd9e6d50c3..000000000000
--- a/lld/test/ELF/lto/Inputs/common.s
+++ /dev/null
@@ -1 +0,0 @@
- .comm a,8,4
diff --git a/lld/test/ELF/lto/Inputs/resolution.s b/lld/test/ELF/lto/Inputs/resolution.s
deleted file mode 100644
index 60b7870efbf4..000000000000
--- a/lld/test/ELF/lto/Inputs/resolution.s
+++ /dev/null
@@ -1,4 +0,0 @@
- .data
- .global a
-a:
- .long 9
diff --git a/lld/test/ELF/lto/bitcode-wrapper.ll b/lld/test/ELF/lto/bitcode-wrapper.ll
new file mode 100644
index 000000000000..183d8c28383b
--- /dev/null
+++ b/lld/test/ELF/lto/bitcode-wrapper.ll
@@ -0,0 +1,55 @@
+; REQUIRES: x86
+
+;; The LLVM bitcode format allows for an optional wrapper header. This test
+;; shows that LLD can handle bitcode wrapped in this way, and also that an
+;; invalid offset in the wrapper header is handled cleanly.
+
+; RUN: rm -rf %t
+; RUN: split-file %s %t
+; RUN: llvm-as %t/ir.ll -o %t.bc
+
+;; Basic case:
+; RUN: %python %t/wrap_bitcode.py %t.bc %t.o 0 0x14
+; RUN: ld.lld %t.o -o %t.elf
+; RUN: llvm-readelf -s %t.elf | FileCheck %s
+
+;; Padding between wrapper header and body:
+; RUN: %python %t/wrap_bitcode.py %t.bc %t.o 0x10 0x24
+; RUN: ld.lld %t.o -o %t.elf
+; RUN: llvm-readelf -s %t.elf | FileCheck %s
+
+; CHECK: _start
+
+;; Invalid offset past end of file:
+; RUN: %python %t/wrap_bitcode.py %t.bc %t2.o 0x10 0xffffffff
+; RUN: not ld.lld %t2.o -o %t2.elf 2>&1 | FileCheck %s --check-prefix=ERR1 -DFILE=%t2.o
+
+; ERR1: error: [[FILE]]: Invalid bitcode wrapper header
+
+;; Invalid offset within file:
+; RUN: %python %t/wrap_bitcode.py %t.bc %t3.o 0x10 0x14
+; RUN: not ld.lld %t3.o -o %t3.elf 2>&1 | FileCheck %s --check-prefix=ERR2 -DFILE=%t3.o
+
+; ERR2: error: [[FILE]]: file doesn't start with bitcode header
+
+;--- ir.ll
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+ at _start = global i32 0
+
+;--- wrap_bitcode.py
+## Arguments are: input file, output file, padding size, offset value.
+import struct
+import sys
+
+with open(sys.argv[1], 'rb') as input:
+ bitcode = input.read()
+
+padding = int(sys.argv[3], 16) * b'\0'
+offset = int(sys.argv[4], 16)
+header = struct.pack('<IIIII', 0x0B17C0DE, 0, offset, len(bitcode), 0)
+with open(sys.argv[2], 'wb') as output:
+ output.write(header)
+ output.write(padding)
+ output.write(bitcode)
diff --git a/lld/test/ELF/lto/common.ll b/lld/test/ELF/lto/common.ll
index e76ca7f9e375..8731b78bfc46 100644
--- a/lld/test/ELF/lto/common.ll
+++ b/lld/test/ELF/lto/common.ll
@@ -1,8 +1,26 @@
; REQUIRES: x86
-; RUN: llvm-as %s -o %t1.o
-; RUN: llvm-mc -triple=x86_64-pc-linux %p/Inputs/common.s -o %t2.o -filetype=obj
-; RUN: ld.lld %t1.o %t2.o -o %t.so -shared
-; RUN: llvm-readobj -S --symbols %t.so | FileCheck %s
+
+;; Show that common symbols defined in both native objects and bitcode files are
+;; properly resolved.
+
+; RUN: rm -rf %t.dir
+; RUN: split-file %s %t.dir
+; RUN: cd %t.dir
+
+;; Case 1: bitcode file has smaller symbol but larger alignment.
+; RUN: llvm-as smaller-sym.ll -o smaller-sym.bc
+; RUN: llc -filetype=obj larger-sym.ll -o larger-sym.o
+; RUN: ld.lld smaller-sym.bc larger-sym.o -o 1.so -shared
+; RUN: llvm-readobj -S --symbols 1.so | FileCheck %s -DALIGN=8
+
+;; Case 2: bitcode file has larger symbol but smaller alignment.
+; RUN: llvm-as larger-sym.ll -o larger-sym.bc
+; RUN: llc -filetype=obj smaller-sym.ll -o smaller-sym.o
+; RUN: ld.lld smaller-sym.o larger-sym.bc -o 2.so -shared
+;; FIXME: This alignment should be 8, but LLD is ignoring the alignment of a
+;; symbol in a native object file when the larger symbol is in a bitcode file.
+;; See https://bugs.llvm.org/show_bug.cgi?id=47819.
+; RUN: llvm-readobj -S --symbols 2.so | FileCheck %s -DALIGN=4
; CHECK: Name: .bss
; CHECK-NEXT: Type: SHT_NOBITS
@@ -12,20 +30,27 @@
; CHECK-NEXT: ]
; CHECK-NEXT: Address:
; CHECK-NEXT: Offset:
-; CHECK-NEXT: Size: 8
+; CHECK-NEXT: Size: 2
; CHECK-NEXT: Link: 0
; CHECK-NEXT: Info: 0
-; CHECK-NEXT: AddressAlignment: 8
+; CHECK-NEXT: AddressAlignment: [[ALIGN]]
; CHECK: Name: a
; CHECK-NEXT: Value:
-; CHECK-NEXT: Size: 8
+; CHECK-NEXT: Size: 2
; CHECK-NEXT: Binding: Global
; CHECK-NEXT: Type: Object
; CHECK-NEXT: Other: 0
; CHECK-NEXT: Section: .bss
+;--- smaller-sym.ll
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+ at a = common global i8 0, align 8
+
+;--- larger-sym.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
- at a = common global i32 0, align 8
+ at a = common global i16 0, align 4
diff --git a/lld/test/ELF/lto/non-ascii-filenames.ll b/lld/test/ELF/lto/non-ascii-filenames.ll
new file mode 100644
index 000000000000..3abdc84401fb
--- /dev/null
+++ b/lld/test/ELF/lto/non-ascii-filenames.ll
@@ -0,0 +1,21 @@
+; REQUIRES: x86
+
+;; Show that both regular LTO and ThinLTO work correctly when an input file uses
+;; a non-ascii filename.
+
+;; Regular LTO.
+; RUN: llvm-as %s -o %t£.o
+; RUN: ld.lld %t£.o -o %t
+; RUN: llvm-readelf -s %t | FileCheck %s
+
+;; Thin LTO.
+; RUN: opt -module-summary %s -o %t-thin£.o
+; RUN: ld.lld %t-thin£.o -o %t-thin
+; RUN: llvm-readelf -s %t-thin | FileCheck %s
+
+; CHECK: _start
+
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+ at _start = global i32 0
diff --git a/lld/test/ELF/lto/resolution.ll b/lld/test/ELF/lto/resolution.ll
index ce6f4d0b3b59..277ad467b442 100644
--- a/lld/test/ELF/lto/resolution.ll
+++ b/lld/test/ELF/lto/resolution.ll
@@ -1,8 +1,16 @@
; REQUIRES: x86
-; RUN: llvm-as %s -o %t1.o
-; RUN: llvm-mc -triple=x86_64-pc-linux %p/Inputs/resolution.s -o %t2.o -filetype=obj
+;; Show that resolution of weak + global symbols works correctly when one is
+;; defined in native object and the other in a bitcode file.
+;; The global symbol in both cases should be kept. LTO should throw away the
+;; data for the discarded weak symbol defined in bitcode. The data for the
+;; weak symbol in a native object will be kept, but will be unlabelled.
+
+; RUN: rm -rf %t.dir
+; RUN: split-file %s %t.dir
+; RUN: llvm-as %t.dir/1.ll -o %t1.o
+; RUN: llvm-mc -triple=x86_64-pc-linux %t.dir/2.s -o %t2.o -filetype=obj
; RUN: ld.lld %t1.o %t2.o -o %t.so -shared
-; RUN: llvm-readobj -S --section-data %t.so | FileCheck %s
+; RUN: llvm-readobj --symbols -S --section-data %t.so | FileCheck %s
; CHECK: Name: .data
; CHECK-NEXT: Type: SHT_PROGBITS
@@ -10,18 +18,36 @@
; CHECK-NEXT: SHF_ALLOC
; CHECK-NEXT: SHF_WRITE
; CHECK-NEXT: ]
-; CHECK-NEXT: Address:
+; CHECK-NEXT: Address: 0x[[#%x,ADDR:]]
; CHECK-NEXT: Offset:
-; CHECK-NEXT: Size: 4
-; CHECK-NEXT: Link: 0
-; CHECK-NEXT: Info: 0
-; CHECK-NEXT: AddressAlignment: 1
-; CHECK-NEXT: EntrySize: 0
+; CHECK-NEXT: Size: 12
+; CHECK-NEXT: Link:
+; CHECK-NEXT: Info:
+; CHECK-NEXT: AddressAlignment:
+; CHECK-NEXT: EntrySize:
; CHECK-NEXT: SectionData (
-; CHECK-NEXT: 0000: 09000000 |{{.*}}|
+; CHECK-NEXT: 0000: 09000000 05000000 04000000 |{{.*}}|
; CHECK-NEXT: )
+; CHECK: Name: a{{ }}
+; CHECK-NEXT: Value: 0x[[#%x,ADDR]]
+
+; CHECK: Name: b{{ }}
+; CHECK-NEXT: Value: 0x[[#%x,ADDR+8]]
+
+;--- 1.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@a = weak global i32 8
+ at b = global i32 4
+
+;--- 2.s
+.data
+.global a
+a:
+.long 9
+
+.weak b
+b:
+.long 5
More information about the llvm-commits
mailing list