[all-commits] [llvm/llvm-project] 734291: [clang][IFS] Driver Pipeline: generate stubs after...

[Puyan Lotfi via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 73429126c91c2065c6f6ef29b3eec1b7798502bb
      https://github.com/llvm/llvm-project/commit/73429126c91c2065c6f6ef29b3eec1b7798502bb
  Author: Puyan Lotfi <puyan at puyan.org>
  Date:   2019-11-20 (Wed, 20 Nov 2019)

  Changed paths:
    M clang/lib/Driver/Driver.cpp
    M clang/lib/Driver/ToolChains/InterfaceStubs.cpp
    M clang/lib/Driver/Types.cpp
    M clang/test/InterfaceStubs/driver-test.c
    A clang/test/InterfaceStubs/driver-test2.c
    A clang/test/InterfaceStubs/ppc.cpp
    M clang/test/InterfaceStubs/windows.cpp

  Log Message:
  -----------
  [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