iains / gcc-darwin-arm64

GCC master branch for Darwin with experimental support for Arm64. Currently GCC-15.0.0 [September 2024]
GNU General Public License v2.0
269 stars 33 forks source link

arm-none-eabi-gcc 10.3.1 on Apple Silicon? #49

Closed ilg-ul closed 2 years ago

ilg-ul commented 2 years ago

I know that this project focuses on native GCC, but I guess some of your experience might help for cross-compilers too.

I'm trying to compile the GNU Arm Embedded Toolchain on a new Mac, and the build went up to:

g++-xbb -fno-PIE -c  -DIN_GCC_FRONTEND -ffunction-sections -fdata-sections -pipe -O2 -w -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc -I/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc/. -I/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc/../include -I/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc/../libcpp/include  -I/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc/../libdecnumber -I/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc/../libbacktrace  -I/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/install/libs/include  -o cc1-checksum.o -MT cc1-checksum.o -MMD -MP -MF ./.deps/cc1-checksum.TPo cc1-checksum.c
Undefined symbols for architecture arm64:
  "_host_hooks", referenced from:
      __Z14gt_pch_restoreP7__sFILE in libbackend.a(ggc-common.o)
      __Z11gt_pch_saveP7__sFILE in libbackend.a(ggc-common.o)
Undefined symbols for architecture arm64:
  "_host_hooks", referenced from:
      __ZN6toplev4mainEiPPc in libbackend.a(toplev.o)
      __Z14gt_pch_restoreP7__sFILE in libbackend.a(ggc-common.o)
      __Z11gt_pch_saveP7__sFILE in libbackend.a(ggc-common.o)
      __ZN6toplev4mainEiPPc in libbackend.a(toplev.o)
ld: symbol(s) not found for architecture arm64
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status
collect2: error: ld returned 1 exit status
make[1]: *** [/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc/lto/Make-lang.in:92: lto-dump] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/sources/gcc/gcc/lto/Make-lang.in:88: lto1] Error 1
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod
make[1]: Leaving directory '/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.2/darwin-arm64/build/gcc-10.3.1-first/gcc'
make: *** [Makefile:4400: all-gcc] Error 2

I am not very familiar with the GCC internals, but it looks like some platform specific code is missing.

The compiler is expected to generate bare-metal code, so the difficult security issues which you have in the native compiler should not face here, the main challenge would be to build the compiler.

Are there any (reasonably complex) patches that can be applied for this?

Any advice on how to proceed?

ilg-ul commented 2 years ago

BTW, g++-xbb is a GCC 11.1 built from your sources, which seems ok.

iains commented 2 years ago

which source code are you using? I have fixed the cross-compilation on master, but that has not been back-ported to earlier branches - however, I would expect that my 10.3 source (https://github.com/iains/gcc-10-branch/tree/gcc-10-3-apple-si) would build a cross-compiler;

ilg-ul commented 2 years ago

The official gcc-arm-none-eabi-10.3-2021.10-src.tar.bz2 source tarball.

iains commented 2 years ago

ah - well, no, that would not be expected to work - there are a few patches needed to enable host-side support (even to build a cross-compiler). If you need a later source than 10.3 release, then let me know and I'll see what can be done - but applying those changes "upstream" is not even certain - this is a new port, so back ports are not "regression or bug fixes".

... however, I will keep a 10.x and 11.x branch going ;)

ilg-ul commented 2 years ago

Unfortunately I'm stuck with using exactly the same releases as Arm does, so for now it is that archive plus some possible patches.

I tried to figure out the differences by taking a look at your branch, but I would appreciate any hints, since at first sight I did not find anything related to the host hooks.

iains commented 2 years ago

I'll try and isolate what you need - later today, hopefully.

ilg-ul commented 2 years ago

Thank you very much!

iains commented 2 years ago

completely untested 8 patches here https://github.com/iains/gcc-10-branch/tree/gcc-10-aarch64-host

you should add "--disable-libstdcxx-pch" to the configure since I have not added any patches to that to deal with disabling / working round PCH issues (PCH will not work with the patch set above).

====

There is stuff still 'in flux' as to what will be applied to master - it's better not to back port speculative fixes unless there's no choice (so I'm waiting - unless/until there is a branch release imminent)

ilg-ul commented 2 years ago

I'll try this shortly, thank you. Host only is enough for now.

ilg-ul commented 2 years ago

It took me a bit to manage those patches, since the repository used by Arm is not public, and I had to recreate it from the provided archive. :-(

Anyway, I cherry picked your 8 commits, prepared a patch, and added it to my build scripts

The configure step reported Using host-darwin.o host-aarch64-darwin.o for host machine hooks., the build started, but finally failed:

ar: host-aarch64-darwin.o: No such file or directory
make[1]: *** [Makefile:2045: libbackend.a] Error 1
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod
make[1]: Leaving directory '/Users/ilg/Work/arm-none-eabi-gcc-10.3.1-2.3/darwin-arm64/build/gcc-10.3.1-first/gcc'
make: *** [Makefile:4371: all-gcc] Error 2

The reason is that the host-aarch64-darwin.c file is not present.

Is there any other branch where I should search for this file?

iains commented 2 years ago

[Darwin, aarch64 : Initial support for the self-host driver. 3dc354d83366 Iain Sandoe iain@sandoe.co.uk 17 Nov 2021 at 13:08] (https://github.com/iains/gcc-10-branch/commit/3dc354d833663e52c1a9e20827925aeab1ea2c21)

Should have that source file in it ?

ilg-ul commented 2 years ago

I probably messed something, I'll redo the patches.

iains commented 2 years ago

It took me a bit to manage those patches, since the repository used by Arm is not public, and I had to recreate it from the provided archive. :-(

It's usually easiest to create a new git repo with the tarball .. and then add a new point for each succeeding one.

you can export the patch series using 'git format-patch xxx...yyy -o series/ and then apply each one in turn with patch -p1 <series/0xxxx.....

but that has 0 change control ;)

iains commented 2 years ago

It took me a bit to manage those patches, since the repository used by Arm is not public, and I had to recreate it from the provided archive. :-(

It's usually easiest to create a new git repo with the tarball .. and then add a new point for each succeeding one.

one can add a remote without shared history - you might need to override something depending on the git version - but that also works providing, of course, that the sources really are from the same origin.

ilg-ul commented 2 years ago

Right, there is a lot of room for improvements in the way I manage patches :-(

At the second attempt, the development version of the build completed successfully, and the minimalistic tests passed.

I restarted the script to get the production (multi-lib) version; it takes several hours, I'll know tomorrow morning how it went.

ilg-ul commented 2 years ago

Do you think the same patches will also work on a bit older 10.2.0? I have to port the RISC-V toolchain too, and it is based on a patched GCC 10.2.0.

iains commented 2 years ago

no; I am sure that you will need some more patches - the underlying changes for Darwin2x were applied between 10.2 and 10.3 along with some other base changes the port,

at least these (possibly others) from the GCC 10 branch [reverse order as from git log --online - i.e. apply bottom to top] :

093788fb9683 Darwin : Fix out-of-bounds access to df_regs_ever_live.
9982ca0f0e3c Darwin : Simplify headers.
2dc332f7ce48 Darwin : Adjust defaults for current bootstrap constraints.
aa55f33e6cb5 Darwin: Guard two macros in darwin.h.
df11e89be569 Darwin : Avoid a C++ ODR violation seen with LTO.
08d4e37c91b4 Darwin : Begin rework of zero-fill sections.
dc734dad7aee Darwin : Update libc function availability.
a996d8d7a8d0 Darwin: Handle poly_int machine_modes.
c85bc938ccf7 Darwin : Update libtool and dependencies for Darwin20 [PR97865]
7b19b6b15368 Darwin, libsanitizer : Support libsanitizer for x86_64-darwin20.
82abd13fb66e Darwin : Adjust handling of MACOSX_DEPLOYMENT_TARGET for macOS 11.
f5ee16a0d8e3 Darwin : Update the kernel version to macOS version mapping.
24957662c670 Darwin: Darwin 20 is to be macOS 11 (Big Sur).
d0bae0b218d5 Darwin: Adjust the PCH area to allow for 16384byte page size.

You can give it a try - but I don't even know if that series will apply without fixing up individual changes.

ilg-ul commented 2 years ago

I see. I can already build it on Intel 11.6, the problem is only the Arm port.

iains commented 2 years ago

However the configuration for 11.6 on unpatched 10.2 would still be missing those patches - not sure of the exact impact without more study, perhaps it's not significant for host-only code.

Of course, you can always try with only the second set on aarch64... but I suspect that the version reported by the kernel will cause problems with the driver code.

ilg-ul commented 2 years ago

Since the arm-none-eabi-gcc build passed, I'll close this issue.

For the riscv-none-embed-gcc build, I opened a separate ticket (#51).