Created attachment 147691 [details] Patch to allow the build on armv6 The attached patch allows me to build gcc 4.8 on armv6. I've tested patch-arm-support against lang/gcc48, but would expect it to also work with lang/gcc. Due to the time to build on hardware I'm still working on testing there. Arm prior to armv6 should be supported, but this has not been tested. Only FreeBSD 10 and later are supported as it builds for the ARM EABI. As armv6 was added to 10 this shouldn't be a problem, however it will if we also allow arm and armeb to be built.
Auto-assigned to maintainer gerald@FreeBSD.org
1/ Would that patch also work as a cross compiler? 2/ Are you planning to upstream that? Gerald do you have contacts to be able to upstream? Reading at the patch I bet this is enough to generate working arm binaries but not enough to build the kernel am I wrong?
I haven't tried using it as a cross compiler. I would expect it to work but this would need to be tested. The patch is mostly upstreamable, however, by default, gcc assumes armv6 can handle unaligned accesses where we don't support this. The rest of the patch should be able to be upstreamed, there is one minor change that needs to be made to it. I'm planning on testing this change against 4.9 and 5 when I've finished work on 4.8. The patch is lacking our local changes to build the kernel, e.g. format strings. Other than this I don't see why it would fail, assuming gcc 4.8 could build the kernel.
This one is missing: Index: config/arm/unwind-arm.h =================================================================== --- config/arm/unwind-arm.h (revision 215538) +++ config/arm/unwind-arm.h (working copy) @@ -48,7 +48,8 @@ if (!tmp) return 0; -#if (defined(linux) && !defined(__uClinux__)) || defined(__NetBSD__) +#if (defined(linux) && !defined(__uClinux__)) || defined(__NetBSD__) \ + || defined(__FreeBSD__) /* Pc-relative indirect. */ #define _GLIBCXX_OVERRIDE_TTYPE_ENCODING (DW_EH_PE_pcrel | DW_EH_PE_indirect) tmp += ptr;
Andrew, have you run the testsuite? How do the tls testcases work?
After running the test suite I don't think tls is quite right. It needs relocations we don't handle and would take a while to handle correctly. I tried top use gnu tls (over gnu2), however I'm getting errors like this: {standard input}: Assembler messages: {standard input}:241: Error: invalid operands (.text and *UND* sections) for `-' I found the assembly is missing a label used by the tls code, and referenced at the end of some functions.
Building at different optimisation levels I've found it's only a problem at -O1. After disabling various passes I found adding -fno-dse would allow the code to be built, indicating a problem with the dead code elimination pass. NetBSD had the same problem with a prerelease [1], but this appears to be fixed when they imported the 4.8.3 release. [1] http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48841
That should read "... adding -fno-dce would allow the code to be built, ..."
Ok, I've not seen the errors you mention on gcc-trunk. I can bootstrap c/c++ and most of the tests are ok. Only tls seems broken. And, I say it this way, I think argument handling is somehow broken when it comes to an interaction with thread_unwind_stop. Possible that it is an alignment issue.
Another question I have, do you build with clang or with gcc?
(In reply to Andreas Tobler from comment #10) > Another question I have, do you build with clang or with gcc? I'm building with clang.
Created attachment 147919 [details] updated patch to use gnu tls
I've uploaded the patch to https://reviews.freebsd.org/D884 and am running the gcc tests, however these can take 24 hours on a Wandboard.
I'm happy to see the developments around this patch. To get this into ports, I'd really like to see an upstream submission first (by the author(s) if possible, and someone with an FSF copyright assignment ideally). I volunteer, and you can mention that in the submission, to commit the patch once approved. If you have any questions how to best go about it, Andreas Tobler and me should be able to help. In any case, can this please target the latest version of lang/gcc*, i.e. lang/gcc5 right now? Doing this for a GCC 4.8 based compiler automatically introduces a regression with GCC 4.9 and GCC 5 based compilers. (In the case of aarch64, my recommendation is to default to lang/gcc5 or lang/gcc49 instead of lang/gcc for USE_GCC=yes / USE_GCC=any given how things have evolved since GCC 4.8.)
Here is my current diff for gcc5. It is based on gcc-trunk, not on ports sources. https://people.freebsd.org/~andreast/gcc5_fbsd_arm_20141003-1.diff As of today I can only build with gcc-4.2.1, doing it with clang requires manual intervention when compiling insn-*.c files. Needs to be done. As Andrew wrote, testing consumes quite a lot of time, wandboard too here. I'm not ready for submission yet since the test suite contains too many failures for my opinion. Also some polishing is needed, private comments... Especially one thing bothers me, I can not run a real toplevel parallel test since 'expect' dumps core in an non predictable manner. This makes it hard as I do not always sit next to the board ;)
As of today, lang/gcc (and lang/gcc49) both should support ARM now. :-) Thanks to Andreas for preparing and testing these patches and also submitting them upstream. Getting them accepted upstream is the next step.