Fix le32 linking issue by treating ".bc" as ".o".
This issue occurs only when bitcode filename ends with .bc,
filename ends with ".o" or ".so" doesn't have such problem.
Issue description:
Assume libc.bc is already linked by le32-none-ndk-link, and it
contains the bitcode wrapper we needed.
clang -shared -emit-llvm -target le32-none-ndk a.bc libc.bc -o b.bc
It takes 3 phases to complete the linking,
(1) clang -cc1 a.bc -emit-llvm-bc -target le32-none-ndk -o /tmp/a.bc
(2) clang -cc1 libc.bc -emit-llvm-bc -target le32-none-ndk -o /tmp/libc.bc
(3) le32-none-ndk-link -shared /tmp/a.bc /tmp/libc.bc -o b.bc
In the second phase, /tmp/libc.bc is generated without bitcode wrapper.
This makes the final linking phase incorrectly.
The solution here is treating ".bc" as ".o", then phase 1 and 2 could be skipped.
Change-Id: Ie55b62d95d8787f4fb778247e75e7617347ab8f0
diff --git a/lib/Driver/Driver.cpp b/lib/Driver/Driver.cpp
index 0940d46..fa15618 100644
--- a/lib/Driver/Driver.cpp
+++ b/lib/Driver/Driver.cpp
@@ -1041,6 +1041,14 @@
types::ID InputType = Inputs[i].first;
const Arg *InputArg = Inputs[i].second;
+ // Let le32-none-ndk treats .bc as .o, so that we don't need to do
+ // the extra compile actions.
+ if (TC.getTriple().getArch() == llvm::Triple::le32 &&
+ TC.getTriple().getOS() == llvm::Triple::NDK) {
+ if (InputType == types::TY_LLVM_BC)
+ InputType = types::TY_Object;
+ }
+
NumSteps = types::getNumCompilationPhases(InputType);
assert(NumSteps && "Invalid number of steps!");
