1; LTO 2; This doesn't currently work with gold, because it does not apply defsym 3; renaming to symbols in the same module (apparently by design for consistency 4; with GNU ld). Because regular LTO hands back a single object file to gold, 5; it doesn't perform the desired defsym renaming. This isn't an issue with 6; ThinLTO which hands back multiple native objects to gold. For regular 7; LTO defsym handling, gold will need a fix (not the gold plugin). 8; RUN-TODO: llvm-as %s -o %t.o 9; RUN-TODO: llvm-as %S/Inputs/wrap-bar.ll -o %t1.o 10; RUN-TODO: %gold -m elf_x86_64 -plugin %llvmshlibdir/LLVMgold%shlibext %t.o %t1.o -shared -o %t.so -wrap=bar 11; RUN-TODO: llvm-objdump -d %t.so | FileCheck %s 12; RUN-TODO: llvm-readobj --symbols %t.so | FileCheck -check-prefix=BIND %s 13 14; ThinLTO 15; RUN: opt -module-summary %s -o %t.o 16; RUN: opt -module-summary %S/Inputs/wrap-bar.ll -o %t1.o 17; RUN: %gold -m elf_x86_64 -plugin %llvmshlibdir/LLVMgold%shlibext %t.o %t1.o -shared -o %t.so -wrap=bar 18; RUN: llvm-objdump -d %t.so | FileCheck %s --check-prefix=THIN 19; RUN: llvm-readobj --symbols %t.so | FileCheck -check-prefix=BIND %s 20 21; Make sure that calls in foo() are not eliminated and that bar is 22; routed to __wrap_bar and __real_bar is routed to bar. 23 24; CHECK: <foo>: 25; CHECK-NEXT: pushq %rax 26; CHECK-NEXT: callq{{.*}}<__wrap_bar> 27; CHECK-NEXT: callq{{.*}}<bar> 28 29; THIN: <foo>: 30; THIN-NEXT: pushq %rax 31; THIN-NEXT: callq{{.*}}<__wrap_bar> 32; THIN-NEXT: popq %rax 33; THIN-NEXT: jmp{{.*}}<bar> 34 35; Check that bar and __wrap_bar retain their original binding. 36; BIND: Name: bar 37; BIND-NEXT: Value: 38; BIND-NEXT: Size: 39; BIND-NEXT: Binding: Local 40; BIND: Name: __wrap_bar 41; BIND-NEXT: Value: 42; BIND-NEXT: Size: 43; BIND-NEXT: Binding: Local 44 45target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" 46target triple = "x86_64-unknown-linux-gnu" 47 48declare void @bar() 49declare void @__real_bar() 50 51define void @foo() { 52 call void @bar() 53 call void @__real_bar() 54 ret void 55} 56