[PATCH] D149087: [lld] Allow input files from compatible architectures on EC targets.

Jacek Caban via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 26 08:34:25 PDT 2023


jacek added inline comments.


================
Comment at: lld/COFF/SymbolTable.cpp:42
+  case ARM64:
+    return mt == ARM64 || mt == ARM64X;
+  case ARM64EC:
----------------
mstorsjo wrote:
> Just to check that I've understood correctly here... We don't really expect the input of an individual object file to ever be `ARM64X`, but only `ARM64`, `AMD64` or `ARM64EC`, while `ARM64X` is an image level flag to indicate that it contains both `ARM64` and (`ARM64EC` or `AMD64`), more or less?
> 
> (I don't mind keeping the case here just for completeness anyway though.)
We do expect ARM64X on input as well. Individual input object file with its machine value of ARM64X are rare and weird, but they do exist and llvm-cvtres can produce them with https://reviews.llvm.org/D148517 I will update patches with tests for them. According to my testing, ARM64X objects are accepted by link.exe for all targets: ARM64, ARM64EC and ARM64X.

In case of linked images, ARM64X is not used as machine type in PE COFF header. ARM64 is used instead and CHPE metadata referenced by load config distinguishes such files from pure ARM64. From linker point of view, CHPE metadata and load config are provided by CRT libraries, but there is a number of synthetic symbols that linker will have to provide that CRT uses to fill it. (I have enough of those symbols prototyped in my tree to get basic ARM64EC working, not yet ARM64X).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149087/new/

https://reviews.llvm.org/D149087



More information about the llvm-commits mailing list