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

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

> I'm still trying to understand the implications of ARM64X are for the traditional compile & link model. My initial understanding was that ARM64X was a standard fat binary system: It's a way to combine two standalone x64 and ARM64EC PE files together into one

Minor nitpick, but ARM64X is a combination of ARM64EC and regular ARM64, not x64. ARM64EC itself is a freefloating mix of actual ARM64EC and regular x64 object files (and identifies as x64, in the COFF machine field).

Linking ARM64EC mostly works as a regular, non-fat link, with one definition of everything, but with lots of thunks inbetween everything, essentially allowing you to jump freely back and forth between AOT compiled ARM64EC and x64 at any function boundary.

> maybe with some transparent way to share .rdata, but what you have said here has made me question everything.
> 
> I'm getting the sense now that this is roughly speaking what a build should look like:
> 
> ```
> $ (clang-)cl *.cpp --target=x86_64-windows-msvc /Fox64/   # Produce a set of x64 object files
> $ (clang-)cl *.cpp --target=arm64ec-windows-msvc /Foarm64ec/   # Produce a set of arm64ec object files
> $ link x64/*.obj arm64/*.obj -out:app.exe  # Combine x64 and arm64ec objects together into one PE
> ```

Almost, I think it's more like this:

```
$ (clang-)cl *.cpp --target=aarch64-windows-msvc /Foarm64/   # Produce a set of regular aarch64 object files
$ (clang-)cl *.cpp --target=arm64ec-windows-msvc /Foarm64ec/ # Produce a set of arm64ec object files, possibly intermixed with x64 too
$ link arm64/*.obj arm64ec/*.obj -out:app.exe  # Combine arm64 and arm64ec objects together into one PE
```


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