xref: /llvm-project/llvm/test/tools/gold/X86/bcsection.ll (revision 4b1e3d19370694dd2b2c04a5945f3f9e43917456)
1; RUN: rm -rf %t && mkdir -p %t
2; RUN: llvm-as -o %t/bcsection.bc %s
3
4; RUN: llvm-mc -I=%t -filetype=obj -triple=x86_64-unknown-unknown -o %t/bcsection.bco %p/Inputs/bcsection.s
5; RUN: llc -filetype=obj -mtriple=x86_64-unknown-unknown -o %t/bcsection-lib.o %p/Inputs/bcsection-lib.ll
6
7; RUN: %gold -shared --no-undefined -o %t/bcsection.so -m elf_x86_64 -plugin %llvmshlibdir/LLVMgold%shlibext %t/bcsection.bco %t/bcsection-lib.o
8
9; This test checks that the gold plugin does not attempt to use the bitcode
10; in the .llvmbc section for LTO.  bcsection-lib.o calls a function that is
11; present the symbol table of bcsection.bco, but not included in the embedded
12; bitcode.  If the linker were to use the bitcode, then the symbols in the
13; symbol table of bcsection.bco will be ignored and the link will fail.
14;
15; bcsection.bco:
16;  .text:
17;    elf_func
18;  .llvmbc:
19;    bitcode_func
20;
21; bcsection-lib.o:
22;   calls elf_func()
23
24target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
25target triple = "x86_64-unknown-unknown"
26
27; CHECK: main
28define i32 @bitcode_func() {
29  ret i32 0
30}
31