Mingw compilation support
This is going to require quite a bit of restructuring.
Step-0 ~~- [ ] Get FEXCore compiling with GCC~~
- [x] Get FEXCore compiling with llvm-mingw
- Necessary instead of GCC path
- https://github.com/mstorsjo/llvm-mingw
Step-1
- [x] Move signal context construction to Loader side
- [x] Drop frontend targets from cmake that won't ever compile with mingw
- [ ] Remove Linux-isms from FEXCore side. Using wrappers where necessary
- This is a big one, quite a few things spread around the source code
- [ ] JITs have some hardcoded assumptions here, might need to redefine some stuff so we can safely do some syscalls still
- [x] Handle SIGBUS/SIGILL FEX requirements in frontend
- Requires a collaboration between FEXCore and FEX frontend to ensure nothing unexpected shows up as a signal frame
Step-2
- [ ] Introduce Build CI so we don't break it
- [ ] Introduce unittesting CI
Step-3
- [ ] Integration
Investigation
- [ ] How well does clang-cl or clang with a windows target work? Would be nice to not need to deal with gcc/mingw compiler problems.
- Initial testing showed linking problems that I couldn't resolve easily.
Looks like building llvm-mingw is very straightforward.
Their instructions for ./build-all.sh <target-dir> works out of the box locally. Might just take a while depending on environment.
Hello, just sticking my head in here, I have a reasonable amount of experience with this :)
You're far better off sticking with clang (GCC is a WIP), and unless you want ABI compatiblity with MSVC, you can use the standard aarch64-w64-windows-gnu target with reasonable success.
May I suggest you use msys2? If you have a Windows ARM64 machine, you can use it directly on that with the "clangarm64" packages. I incidentally am in the process of moving over blender from mingw -> msys2, as it's considerably easier.
Hi, this should help with my effort to get FEX into Hangover! What's your reason to make it mingw-w64 compatible? With having it as PE I think debugging will be improved, which is quite nice. While I already can run some games with Hangover/FEX, I stumble across odd crashes in FEXCores' libstdc++ which are really hard to debug across PE<->Unix boundaries. So +1 for this task :)
Hi, this should help with my effort to get FEX into Hangover! What's your reason to make it mingw-w64 compatible? With having it as PE I think debugging will be improved, which is quite nice. While I already can run some games with Hangover/FEX, I stumble across odd crashes in FEXCores' libstdc++ which are really hard to debug across PE<->Unix boundaries. So +1 for this task :)
The llvm-mingw support is specifically for helping with Wine integration. Since PE side will likely be the more optimal codepath. The current PR for getting llvm-mingw support is an initial build-tested path but there are still linux assumptions sprinkled around. Like calling convention and assuming we can read some EL1 MSRs. In at least the short-term I don't care about actually executing in a ARM64 Windows environment, so some of these assumptions are fine.
With all the llvm-mingw initial build PRs merged, this should now technically work to some extent. If you find anything that we can improve on our side for llvm-mingw support then we would be willing to facilitate that. Since we don't have any testing on our side for this yet, then I don't know the full scope of what is necessary yet.
I guess I need some build instructions, tried this, but didn't work: CC=x86_64-w64-mingw32-clang CXX=x86_64-w64-mingw32-clang++ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Releaseu -DENABLE_LLD=True -DBUILD_TESTS=False -DENABLE_ASSERTIONS=False -DENABLE_X86_HOST_DEBUG=True .. make FEXCore
leads to error when building jemalloc
Yea, jemalloc needs to be disabled for mingw currently.
cmake options: -DENABLE_JEMALLOC=False -DENABLE_JEMALLOC_GLIBC_ALLOC=False.
Implications of this just means that when executing a 32-bit application, FEX will have its memory usage also in the lower 32-bits. Which means that most things will exhaust VA since FEX uses a decent amount.
This has been done for a while.