maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/InterfaceStubs/driver-test.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

14 lines
409 B
C
Raw Normal View History

Revert "[clang][IFS] Driver Pipeline: generate stubs after standard pipeline (2)" This reverts commit ea8e02822341e2421b94167d828d3f224e767424.
2019-11-20 10:59:50 +08:00
// REQUIRES: x86-registered-target
[clang][IFS] Driver Pipeline: generate stubs after standard pipeline (3) Third Landing Attempt (dropping any linker invocation from clang driver): Up until now, clang interface stubs has replaced the standard PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in conjunction with it. So what when you build your code you will get an a.out or lib.so as well as an interface stub file. Example: clang -shared -o libfoo.so -emit-interface-stubs ... will generate both a libfoo.so and a libfoo.ifso. The .so file will contain the code from the standard compilation pipeline and the .ifso file will contain the ELF stub library. Note: For driver-test.c I've added -S in order to prevent any bot failures on bots that don't have the proper linker for their native triple. You could always specify a triple like x86_64-unknown-linux-gnu and on bots like x86_64-scei-ps4 the clang driver would invoke regular ld instead of getting the error 'Executable "orbis-ld" doesn't exist!' but on bots like ppc64be and s390x you'd get an error "/usr/bin/ld: unrecognised emulation mode: elf_x86_64" Differential Revision: https://reviews.llvm.org/D70274
2019-11-21 03:41:11 +08:00
// REQUIRES: shell
Revert "[clang][IFS][test] Removing driver-test.c. Test is still too brittle." This reverts commit f37356d6f60ae5db978611621d3a375ed87ec0f0.
2019-11-20 10:59:10 +08:00
[clang][IFS] Driver Pipeline: generate stubs after standard pipeline (3) Third Landing Attempt (dropping any linker invocation from clang driver): Up until now, clang interface stubs has replaced the standard PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in conjunction with it. So what when you build your code you will get an a.out or lib.so as well as an interface stub file. Example: clang -shared -o libfoo.so -emit-interface-stubs ... will generate both a libfoo.so and a libfoo.ifso. The .so file will contain the code from the standard compilation pipeline and the .ifso file will contain the ELF stub library. Note: For driver-test.c I've added -S in order to prevent any bot failures on bots that don't have the proper linker for their native triple. You could always specify a triple like x86_64-unknown-linux-gnu and on bots like x86_64-scei-ps4 the clang driver would invoke regular ld instead of getting the error 'Executable "orbis-ld" doesn't exist!' but on bots like ppc64be and s390x you'd get an error "/usr/bin/ld: unrecognised emulation mode: elf_x86_64" Differential Revision: https://reviews.llvm.org/D70274
2019-11-21 03:41:11 +08:00
// RUN: mkdir -p %t; cd %t
// RUN: %clang -target x86_64-unknown-linux-gnu -x c -S -emit-interface-stubs %s %S/object.c %S/weak.cpp && \
// RUN: llvm-nm %t/a.out.ifso 2>&1 | FileCheck --check-prefix=CHECK-IFS %s
Revert "[clang][IFS] Driver Pipeline: generate stubs after standard pipeline (2)" This reverts commit ea8e02822341e2421b94167d828d3f224e767424.
2019-11-20 10:59:50 +08:00
// CHECK-IFS-DAG: data
// CHECK-IFS-DAG: foo
// CHECK-IFS-DAG: strongFunc
// CHECK-IFS-DAG: weakFunc
Revert "[clang][IFS][test] Removing driver-test.c. Test is still too brittle." This reverts commit f37356d6f60ae5db978611621d3a375ed87ec0f0.
2019-11-20 10:59:10 +08:00
int foo(int bar) { return 42 + 1844; }