On Wed, 23 Apr 2025, Jacek Caban wrote:
On 22.04.2025 17:21, Martin Storsjö wrote:
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.
To elaborate on this: unlike other functions, the vararg calling convention
differs significantly from aarch64, so we’d need a completely separate
implementation.
Yep - that's probably true. If it would just be to write another
implementation, that wouldn't be too bad though, if it wasn't for all
these other details/issues.
If this gets called from native arm64ec, I guess the thunks on that
side handle the necessary interop. Did you try it?
This is an internal function, called by a few other functions that are built
as ARM64EC, like vsscanf, so it always goes through the exit thunk. And yes,
I tested it.
Ok, thanks for confirming!
BTW, while my recent patches are enough to get a working UCRT
setup, testing msvcrt-os still requires tweaking some F_ARM_ANY usage.
Ok, understandable.
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.
Yeah, I was tempted to just declare msvcrt-os unsupported on ARM64EC ;-). In
general, I aimed for feature parity with aarch64, which does support it,
though a similar argument could be made there as well.
True, it's not entirely important there either, but for testing
orthogonality I've tried to keep aarch64 msvcrt.dll fully functional too.
Side note: The only practical issue I've hit with aarch64 msvcrt.dll is
that it doesn't provide __p__environ, but only _get_environ, so we can't
make "environ" an assignable expression. This breaks building gettext (as
a dependency of VLC) - but with that dependency disabled, everything else
builds just fine.
Originally, I was going to suggest marking just the few functions that depend
on __argtos as unsupported on ARM64EC.
I agree. On its own, all the bits in this patch feel like a bit of a
stretch - but the __guard_dispatch_icall_fptr one really settles it. And
if we do need the build support for x86_64 objects anyway, this one
becomes quite easy in the end. So I agree with this diretion.
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?
Yeah, we'd probably need to require two compilers to be available. That's how
Wine handles it, it looks for a separate compiler for each enabled
architecture, and if ARM64EC is enabled, it also looks for an x86_64 compiler
in addition to the ARM64EC one. Wine’s build system is a lot more flexible in
general, so it was easier to set that up there, but with enough effort,
mingw-w64 could do something similar.
Yes, it's also a little different in how you in Wine may be ok with the
build trying to kinda freely detect what tools you may have available,
that may be useful for the build, while we here quite precisely want to
use the tools for the toolchain we're setting up, not any random ones that
configure may find.
That said, while I’d love to be proven wrong, I don’t expect GCC to support
ARM64EC anytime soon. I think we’re fine ignoring that possibility and
keeping things simple for now and revisiting it if/when it actually becomes
relevant.
I agree - such support feels quite unlikely and quite far away in any
case.
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.
Yes, that’s a limitation, but for the cases where I’ve needed it, it hasn’t
been an issue. Those .S files don’t include any headers anyway.
Ok; as long as we can strive to not require any system headers for the
sources we build to x86_64 objects here, this should be ok.
So - all in all, I don't think there's anything in this patch that I want
to change, so it's ok as is. But it was important to discuss all the
various options available, and why this indeed is the most reasonable
alternative here. Thanks!
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
