On Sat, 12 Apr 2025, Jacek Caban wrote:
A proper ARM64EC implementation would be tricky, as it would need to handle
a different calling convention and possibly use exit thunks for imported
functions. Instead, we can simply use the x86_64 version.
---
I think this sounds reasonable - I guess it'd be quite messy to implement
this in native arm64ec.
If this gets called from native arm64ec, I guess the thunks on that
side handle the necessary interop. Did you try it?
Implementation wise, this is a bit problematic though - as you probably
already thought of. :-) This is a bit annoying, since it's only needed for
msvcrt.dll. We generally shouldn't need to target that much in new arm64ec
builds - but for existing x86_64 deployments, it's quite likely to need to
interop with msvcrt.dll builds. And for orthogonality of testing, for
testing (msvcrt,ucrt) x (all architectures), it makes sense to make sure
the msvcrt config is fully functional even here.
@@ -2337,6 +2345,9 @@ libarm64/gcrt2.o: libarm64/gcrt0.o
libarm64/%.o: crt/%.c
$(AM_V_CC)$(COMPILE) $(CPPFLAGSARM64) -c $< -o $@
+libarm64/%.x86_64.o: %.S
+ $(AM_V_CC)$(MKDIR_P) $(@D) && $(COMPILE) $(CPPFLAGSARM64) -target
x86_64-windows-gnu -c $< -o $@
+
This is a bit problematic - this hardcodes a clang specific way of
requesting a different architecture from a preexisting compiler. (The
other similar option, -m32 and -m64, is compatible across tools.) E.g. if
GCC would gain support for arm64ec, how would we do this? Would we require
the user to have both arm64ec-w64-mingw32-gcc and x86_64-w64-mingw32-gcc
available during the same build?
Secondly, while doing it this Clang specific way - what requirements does
this place on the x86_64 target in the Clang binary? What if I'm building
llvm-mingw with ARCHS=arm64ec, so when using "-target x86_64-w64-mingw32",
it won't find any includes? As this is a .S and not a .c file, it makes
things a bit easier, and this particular file doesn't seem to include any
other files at all, so this particular case probably works.
(Another hypothetical case would be if Clang would be built with
LLVM_TARGETS_TO_BUILD="AArch64" only - but we probably don't need to care
about that case.)
So as long as the source file doesn't need anything in the toolchain to be
initialized for the x86_64 target, I guess this would be tolerable. But it
is a pretty big design constraint in how this is built.
As I'm not so intimately familiar with the details of the thunking layer
here and how to convert between x86_64 and arm64ec, I'm not sure how hard
it would be to implement this in native arm64ec code, so I guess I'll have
to take your word for it, that this is the best compromise.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
