[clang] [clang][ARM64X] Support compiling both native and EC objects with -marm64x (PR #207612)

[Martin Storsjö via cfe-commits]

================
@@ -498,6 +498,31 @@ void visualstudio::Linker::ConstructJob(Compilation &C, const JobAction &JA,
   C.addCommand(std::move(LinkCmd));
 }
 
+void tools::ARM64XObjcopy::ConstructJob(Compilation &C, const JobAction &JA,
+                                        const InputInfo &Output,
+                                        const InputInfoList &Inputs,
+                                        const ArgList &Args,
+                                        const char *LinkingOutput) const {
+  // Assume llvm-objcopy is only used for hybrid ARM64X object files.
+  if (Inputs.size() != 2)
+    return;
+
+  std::string ObjcopyPath = getToolChain().GetProgramPath("llvm-objcopy");
+  const char *Exec = Args.MakeArgString(ObjcopyPath);
+
+  // Embed the hybrid object in the .obj.arm64ec section.
+  ArgStringList CmdArgs;
+  CmdArgs.push_back(Args.MakeArgString("--add-section=.obj.arm64ec=" +
+                                       Twine(Inputs[0].getFilename())));
+  // Mark the .obj.arm64ec section as discardable.
+  CmdArgs.push_back("--set-section-flags=.obj.arm64ec=debug");
+  CmdArgs.push_back(Inputs[1].getFilename());
----------------
mstorsjo wrote:

I somehow feel that the order of the `Inputs[]` should be the other way around - `Inputs[0]` being the main native file (which remains the outer file in the end) and `Inputs[1]` being the one that gets embedded. I presume that this doesn't make any practical difference, other than having the callers order them the other way?

https://github.com/llvm/llvm-project/pull/207612