ARM64EC allows having both pure ARM64 objects and ARM64EC in the same archive. This allows using single static library for linking pure ARM64, pure ARM64EC or mixed modules (what MS calls ARM64X: a single module that may be used in both modes). To achieve that, such static libraries need two separated symbol maps. The usual map contains only pure ARM64 symbols, while a new /<ECSYMBOLS>/ section contains EC symbols. EC symbols map has very similar format to the usual map, except it doesn't contain object offsets and uses offsets from regular map instead. This is true even for pure ARM64EC static library: it will simply have 0 symbols in the symbol map.
Details
Diff Detail
Event Timeline
I'll try to find time to review in more detail soon... unless someone else wants to review. (I'm not really that familiar with this code, but I doubt anyone has looked at it in years anyway.) Leaving a couple quick comments from my first glance.
If you're going to number your patches, please use some sort of consistent numbering... but you don't need to number a "series" like this. Just stacking them in Phabricator is enough. Maybe change the refactoring patches to explicitly put [NFC] in the title.
llvm/lib/Object/ArchiveWriter.cpp | ||
---|---|---|
574 | T.isWindowsArm64EC() | |
llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp | ||
262 | Do we need to mess with this inference code to make mixed archives work correctly? |
Thanks! The new version implements better logic for inferred machine type. I'm not sure if there are any recommendations about compatibility: I checked with lib.exe and it simply always requires explicit machine type for ARM64EC. If I try to create pure ARM64EC library with no -machine: argument, it just fails. I guess it's fine to do better than that, but I may follow that if preferred.
The new version also allows including x86_64 object files in ARM64EC libraries. I originally avoided expressing target in writeArchive call, but it now doesn't have enough info to decide what kind of symbol map to produce (if only x86_64 binaries are passed, it can't deduce if it's meant to be x86_64 or ARM64EC library).
I also added a few more tests and I will add another patch to llvm-nm for printing EC symbol map, which allows for better tests.
I reconsidered support for inferring ARM64EC target from object files and followed MSVC lib, which requires an explicit -machine argument. This makes the patch a bit smaller. Allowing inferring machine type makes type checks much weaker and could potentially unintentionally allow users to mix x86_64 and aarch64 objects. I don't have strong opinion on this, I will restore that code if it's preferred. I also rebased the patch.
Hello and good afternoon from the UK,
I believe this is 1 of 3 patches that may have caused the following build bot to begin failing, are you able to take a look?
https://lab.llvm.org/buildbot/#/builders/216/builds/20269
Warm regards,
Tom W
Yes, sorry about that. I created https://reviews.llvm.org/D148922 with missing REQUIRES statements.
T.isWindowsArm64EC()