[lld] [LLD][COFF] Add support for alternate entry point in CHPE metadata on ARM64X (PR #123346)

[Martin Storsjö via llvm-commits]

================
@@ -2352,6 +2352,23 @@ void Writer::setECSymbols() {
       delayIatCopySym, "__hybrid_auxiliary_delayload_iat_copy",
       delayIdata.getAuxIatCopy().empty() ? nullptr
                                          : delayIdata.getAuxIatCopy().front());
+
+  if (ctx.hybridSymtab) {
+    // For the hybrid image, set the alternate entry point to the EC entry
+    // point. In the hybrid view, it is swapped to the native entry point
+    // using ARM64X relocations.
+    if (auto altEntrySym = cast_or_null<Defined>(ctx.hybridSymtab->entry)) {
+      // If the entry is an EC export thunk, use its target instead.
+      if (auto thunkChunk =
+              dyn_cast<ECExportThunkChunk>(altEntrySym->getChunk()))
+        altEntrySym = thunkChunk->target;
+      Symbol *nativeEntrySym =
+          symtab->findUnderscore("__arm64x_native_entrypoint");
+      replaceSymbol<DefinedAbsolute>(
+          nativeEntrySym, ctx, "__arm64x_native_entrypoint",
+          ctx.config.imageBase + altEntrySym->getRVA());
----------------
mstorsjo wrote:

Can we assume that addresses have been finalized at this point?

Replacing a symbol with a `DefinedAbsolute`, which is manually constructed to point at another symbol feels weird. For relocations against a `DefinedAbsolute`, do we get the base relocation generated?

It somehow feels like it would be more natural to just overwrite this symbol with the contents of the entry point symbol - iirc we do that in a couple other places, so we don't need to do the address calculation manually here.

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