[lld] [LLD][COFF] Add support for CHPE redirection metadata. (PR #105739)

[Jacek Caban via llvm-commits]

================
@@ -749,6 +749,17 @@ class ECCodeMapChunk : public NonSectionChunk {
   std::vector<ECCodeMapEntry> ↦
 };
 
+class CHPERedirectionChunk : public NonSectionChunk {
----------------
cjacek wrote:

I'm not aware of this being explicitly documented. It's used in CHPE metadata, which is a somewhat public name; that's how it's referred to in the IMAGE_LOAD_CONFIG_DIRECTORY64 structure. The __chpe_metadata is somewhat public too - it’s explicitly referenced by the linker in the case of hybrid ARM64X images. These images have two separate load configurations but a single CHPE metadata, so the native load config can't directly reference the ARM64EC __chpe_metadata symbol, and the linker needs to look it up and use it to modify the load config instead.

Another place where this is named is in the __arm64x_redirection_metadata symbol from this PR. Note that it uses "arm64x," not "arm64ec." I think there is some ambiguity about what "arm64x" means. I usually use it to refer to hybrid files (as implied by -machine:arm64x) as ARM64X, while PE files containing only ARM64EC code (as implied by -machine:arm64ec) are referred to as ARM64EC. However, I'm no longer sure if this is the intended nomenclature. I’ve seen the ARM64X name used for both image types, so I guess ARM64X would refer to PE files containing ARM64EC code, while ARM64EC is the name of the ABI. As such, using ARM64X here would also be correct.

That said, I can see arguments for using any of the CHPE, ARM64EC, or ARM64X variants. I chose CHPE to emphasize that it's a part of CHPE metadata, but I wouldn't mind renaming it if you feel differently.

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