"Richard Earnshaw (lists)" <richard.earns...@arm.com> writes: > On 21/02/2024 17:47, Evgeny Karpov wrote: >> Hello, >> >> We would like to take your attention to the review of changes for the >> new GCC target, aarch64-w64-mingw32. The new target will be >> supported, tested, added to CI, and maintained by Linaro. This marks >> the first of three planned patch series contributing to the GCC C >> compiler's support for Windows Arm64. >> >> 1. Minimal aarch64-w64-mingw32 C implementation to cross-compile >> hello-world with libgcc for Windows Arm64 using MinGW. >> 2. Extension of the aarch64-w64-mingw32 C implementation to >> cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All >> packages successfully pass tests. >> 3. Addition of call stack support for debugging, resolution of >> optimization issues in the C compiler, and DLL export/import for the >> aarch64-w64-mingw32 target. >> >> This patch series introduces the 1st point, which involves building >> hello-world for the aarch64-w64-mingw32 target. The patch depends on >> the binutils changes for the aarch64-w64-mingw32 target that have >> already been merged. >> >> The binutils should include recent relocation fixes. >> f87eaf8ff3995a5888c6dc4996a20c770e6bcd36 >> aarch64: Add new relocations and limit COFF AArch64 relocation offsets >> >> The series is structured in a way to trivially show that it should not >> affect any other targets. >> >> In this patch, several changes have been made to support the >> aarch64-w64-mingw32 target for GCC. The modifications include the >> definition of the MS ABI for aarch64, adjustments to FIXED_REGISTERS >> and STATIC_CHAIN_REGNUM for different ABIs, and specific definitions >> for COFF format on AArch64. Additionally, the patch reuses MinGW >> <stdint.h> types and definitions from i386, relocating them to a new >> mingw folder for shared usage between both targets. >> >> MinGW-specific options have been introduced for AArch64, along with >> override options for aarch64-w64-mingw32. Builtin stack probing for >> override options for aarch64-w64-mingw32. Builtin stack probing for >> AArch64 has been enabled as an alternative for chkstk. Symbol name >> encoding and section information handling for aarch64-w64-mingw32 have >> been incorporated, and the MinGW environment has been added, which >> will also be utilized for defining the Cygwin environment in the >> future. >> >> The patch includes renaming "x86 Windows Options" to "Cygwin and MinGW >> Options," which now encompasses AArch64 as well. AArch64-specific >> Cygwin and MinGW Options have been introduced for the unique >> requirements of the AArch64 architecture. >> >> Function type declaration and named sections support have been added. >> The necessary objects for Cygwin and MinGW have been built for the >> aarch64-w64-mingw32 target, and relevant files such as msformat-c.cc >> and winnt-d.cc have been moved to the mingw folder for reuse in >> AArch64. >> >> Furthermore, the aarch64-w64-mingw32 target has been included in both >> libatomic and libgcc, ensuring support for the AArch64 architecture >> within these libraries. These changes collectively enhance the >> capabilities of GCC for the specified target. >> >> Coauthors: Zac Walker <zacwal...@microsoft.com>, >> Mark Harmstone <m...@harmstone.com> and >> Ron Riddle <ron.rid...@microsoft.com> >> >> Refactored, prepared, and validated by >> Radek Barton <radek.bar...@microsoft.com> and >> Evgeny Karpov <evgeny.kar...@microsoft.com> >> >> Special thanks to the Linaro GNU toolchain team for internal review >> and assistance in preparing the patch series! >> >> Regards, >> Evgeny > > Thanks for posting this.
Seconded. :) Thanks also for the very clear organisation of the series, and for commonising code rather than cut-&-pasting it. FWIW, I agree with all the comments posted so far, and just sent some other comments too. I think my main high-level comments are: - Could you double-check that all the code in the common files are used on both aarch64 and x86? I think it's OK to move code outside of x86 even if aarch64 doesn't want to use it, provided that it makes conceptual target-independent sense. But it's not clear whether unused code is deliberate or not (e.g. the EXTRA_OS_CPP_BUILTINS thing I mentioned in the part 2 review). - Could you test with all languages enabled, and say what languages are supported? Some languages require an existing compiler for the same language and so are more difficult to bootstrap for a new port. I suppose you'd need a cross-host build first, then use the cross-compiled compilers to bootstrap. Thanks, Richard
