[lld] [LLD][COFF] Store reference to SymbolTable instead of COFFLinkerContext in InputFile (NFC) (PR #119296)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

So, while the changes to support ARM64EC so far have been quite gradual and non-intrusive, I think this bit changes the fundamental workings of the linker enough that I want most key stakeholders to be aware of it before proceeding. So CC @rnk @aganea @alvinhochun @zmodem @tru (am I missing any other regular LLD/COFF contributors?)

To summarize things very briefly; ARM64EC is the special ABI, using the x86_64 ABI style, with code compiled for aarch64 but fitting into an x86_64 ABI world, where some code is emulated and some is AOT compiled aarch64 code. (That's the easy way to view it; in practice, an ARM64EC DLL can mix between regular x86_64 code and ARM64EC code on a per-function basis.) This is pretty much implemented and functional now, as far as I know.

ARM64X is the case when you'd essentially have a fat binary, mixing ARM64EC and regular native ARM64 binaries into one single DLL/EXE. Contrary to e.g. MachO fat binaries, this isn't two separate binaries that just are glued together, but it is essentially one single binary, that can e.g. share rdata sections, and share functions that happen to be identical between the two modes. This means that instead of having 100% overhead of such a dual-mode binary, Microsoft says that the actual overhead in their setups is around 30%. So instead of having a "fat binary", they have a "hybrid binary". See http://www.emulators.com/docs/abc_arm64ec_explained.htm for more references on this.

In essence, in order to be able to link such a hybrid binary, we need to have two symbol tables in flight at the same time, for each mode. This is probably a notable fundamental change to how LLD/COFF works. But if we want to handle ARM64X, I think it's unavoidable.

So this isn't really phrased as a "do you think we should do it?" question, but just a headsup that this is what is happening here and that we'll probably proceed with (after regular proper code review of course), unless there are strong objections against it of course.

(I haven't yet had time to actually start reviewing this set of changes, but will try to get started on it soon.)

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