================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
