[lld] [LLD][COFF] Emit base relocation for native CHPE metadata pointer on ARM64X (PR #121500)

[Martin Storsjö via llvm-commits]

================
@@ -2594,6 +2594,38 @@ void Writer::createDynamicRelocs() {
                              LOAD_CONFIG_TABLE * sizeof(data_directory) +
                              offsetof(data_directory, Size),
                          0);
+
+  // Insert a 64-bit relocation for CHPEMetadataPointer. Its value will be set
+  // later in prepareLoadConfig to match the value in the EC load config.
+  // However, a base relocation must be allocated in advance, so we handle it
+  // here.
+  if (ctx.symtab.loadConfigSym && ctx.hybridSymtab->loadConfigSym &&
+      ctx.symtab.loadConfigSize >=
+          offsetof(coff_load_configuration64, CHPEMetadataPointer) +
+              sizeof(coff_load_configuration64::CHPEMetadataPointer)) {
+    DefinedRegular *sym = ctx.symtab.loadConfigSym;
+    SectionChunk *chunk = sym->getChunk();
+    ArrayRef<coff_relocation> curRelocs = chunk->getRelocs();
+    MutableArrayRef<coff_relocation> newRelocs(
+        bAlloc().Allocate<coff_relocation>(curRelocs.size() + 1),
+        curRelocs.size() + 1);
+    size_t chpeOffset = sym->getValue() + offsetof(coff_load_configuration64,
+                                                   CHPEMetadataPointer);
+    size_t i;
+    for (i = 0;
+         i < curRelocs.size() && curRelocs[i].VirtualAddress < chpeOffset; ++i)
+      newRelocs[i] = curRelocs[i];
+    newRelocs[i].VirtualAddress = chpeOffset;
+    // The specific symbol used here is irrelevant as long as it's valid, since
+    // it will be overridden by prepareLoadConfig. Use the load config symbol
+    // itself.
+    newRelocs[i].SymbolTableIndex =
----------------
mstorsjo wrote:

The whole logic of allocating a whole new array of relocations, inserting a new element at the right location within it, and replacing the relocations array with the new one, feels a bit complex, when it is interleaved with the actual logic that we're trying to add here. (Also, allocating a whole new array every time we want to add one dynamic relocation feels a bit clumsy, but I'm not sure if that's an issue in practice.)

Is it possible to abstract away the mechanism of adding new dynamic relocations into an entry, so that we can separate the logic for the contents of the new relocation, and the mechanics of allocate+insert+replace?

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