[lld] [LLD][COFF] Introduce hybrid symbol table for EC input files on ARM64X (PR #119294)

[Jacek Caban via llvm-commits]

================
@@ -129,7 +129,7 @@ void SectionChunk::applyRelX64(uint8_t *off, uint16_t type, OutputSection *os,
   case IMAGE_REL_AMD64_REL32_4:  add32(off, s - p - 8); break;
   case IMAGE_REL_AMD64_REL32_5:  add32(off, s - p - 9); break;
   case IMAGE_REL_AMD64_SECTION:
-    applySecIdx(off, os, file->ctx.outputSections.size());
+    applySecIdx(off, os, file->symtab.ctx.outputSections.size());
----------------
cjacek wrote:

This change stems from addressing the opposite scenario: determining the correct symtab from the input file. With hybrid images and two namespaces, `file->ctx.symtab` isn’t always accurate. EC files should use the hybrid symbol table instead, which would look something like `file->ctx.getSymtab(file->getMachineType())` in this PR.

My initial draft followed this approach (encapsulated in an `InputFile` helper) and updated all relevant code to utilize it. However, this approach felt suboptimal - it distributed complexity across the codebase and increased the risk of mistakes or omissions. Instead, storing `symtab` directly in `InputFile` and determining the correct symbol table during object construction made it easier to access and encapsulated the complexity.

I considered storing both `COFFLinkerContext` and `SymbolTable` references in the `InputFile` class. This would allow both `file->ctx` and `file->symtab` to work. However, since the context is easily accessible from the symbol table, this approach felt redundant. To save memory, I opted to store only `symtab`, replacing `file->ctx` with `file->symtab.ctx` as seen in #119296.

The required changes to use `file->symtab.ctx` seemed manageable to me. Additionally, with further refactoring, the number of such instances will likely decrease. For instance, commit 48b055dbd4961f4c in #119298 removes many such cases. Another example would be updating `ImportThunkChunk` to store `symtab` instead of `ctx`, further reducing these instances.

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