[lld] [LLD][COFF] Add support for including native ARM64 objects in ARM64EC images (PR #137653)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

> Another situation where I encountered native objects was with import libraries. ARM64EC import libraries use native object files for import descriptors. This doesn’t affect LLD much since we synthesize them anyway, but MSVC appears to rely on them (see #84834), so it needs to support native object files.

That's a good point. The fact that LLD doesn't actually touch the import library header/footer object files but just makes up its own, is a bit odd at times. Not sure if that's going to change at some point though, but if it would, I guess we'd need this.

> I don’t have a strong real-world example that requires this, and in fact, using native objects with code is probably almost always a bad idea. One acceptable case might be resource object files. Hypothetically, someone could use an aarch64 build system to build ARM64EC binaries by passing something like `CFLAGS=-arm64EC`. That wouldn't affect `cvtres`, so its output would remain a native aarch64 object. MSVC handles that fine, but current LLD would reject it.

Thanks, that's also a reasonable real-world case. (Although in MSVC style build systems one usually just passes the plain `.res` files to the linker and let the linker convert it to object file form.)

> That said, I don’t have a strong reason why we need to support this. Now that we have ARM64X support, it was easy to implement when I came across it again. My thought was that it might be a good time to finalize this part of the code while it’s still fresh. But if you don’t think it’s worthwhile, I will skip it.

I think it can be reasonable to include it, to make our implementation a bit more consistent with MS link.exe. Perhaps it would be good to add a comment, e.g. in `LinkerDriver::setMachine`, that we always create 2 symbol tables for that case, even if one is mostly ignored, to make the design decision stand out a bit more.

As I mentioned somwehere, my reaction to reviewing the PR was mostly that it was a lot of changes, but it probably doesn't add much to the overall complexity of LLD, it just changes the existing code. So given these explanations, I think this change may be ok to merge.

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