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/ppc.cpp

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

15 lines
426 B
C++
Raw Normal View History

[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: powerpc-registered-target
// RUN: %clang -x c++ -target powerpc64le-unknown-linux-gnu -o - %s \
// RUN: -emit-interface-stubs -emit-merged-ifs -S | \
// RUN: FileCheck -check-prefix=CHECK-IFS %s
[llvm][clang][IFS] Enhancing the llvm-ifs yaml format for symbol lists. Prior to this change the clang interface stubs format resembled something ending with a symbol list like this: Symbols: a: { Type: Func } This was problematic because we didn't actually want a map format and also because we didn't like that an empty symbol list required "Symbols: {}". That is to say without the empty {} llvm-ifs would crash on an empty list. With this new format it is much more clear which field is the symbol name, and instead the [] that is used to express an empty symbol vector is optional, ie: Symbols: - { Name: a, Type: Func } or Symbols: [] or Symbols: This further diverges the format from existing llvm-elftapi. This is a good thing because although the format originally came from the same place, they are not the same in any way. Differential Revision: https://reviews.llvm.org/D76979
2020-03-28 16:08:27 +08:00
// CHECK-IFS: --- !experimental-ifs-v2
// CHECK-IFS: IfsVersion: 2.0
// CHECK-IFS: Triple: powerpc64le
// CHECK-IFS: Symbols:
// CHECK-IFS: - { Name: _Z8helloPPCv, Type: Func }
// CHECK-IFS: ...
[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
int helloPPC();