11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float)

Mark Millard markmi at dsl-only.net
Sun May 29 06:00:42 UTC 2016

On 2016-May-28, at 9:50 PM, Warner Losh <imp at bsdimp.com> wrote:

> On Wed, May 25, 2016 at 10:12 AM, Mark Millard <markmi at dsl-only.net> wrote:
>> I'm  not sure that Gerald or Brooks were CC'd on a report made to the arm list about armv6 builds of gcc and llvm being broken now because of hard float now being implicit:
>> (the first report listed below has more detail directly visible for gcc examples)
>> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013931.html
>> and:
>> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013930.html
>> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013932.html
>> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013933.html
>> The first (013931.html) shows that xgcc for configure:3686 for contest.c ends up with the likes of:
>> /usr/local/bin/ld: error: a.out uses VFP register arguments,
>> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o does not
>> /usr/local/bin/ld: failed to merge target specific data of file
>> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o
>> /usr/local/bin/ld: error: a.out uses VFP register arguments,
>> /tmp//cchNL2QG.o does not
>> /usr/local/bin/ld: failed to merge target specific data of file /tmp//cchNL2QG.o
>> /usr/local/bin/ld: error: a.out uses VFP register arguments,
>> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o does not
>> /usr/local/bin/ld: failed to merge target specific data of file
>> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o
>> collect2: error: ld returned 1 exit status
>> and points to gcc/config.gcc only having TARGET_FREEBSD_ARM_HARD_FLOAT=1 for arm*hf-*-freebsd* . But now armv6*-*-freebsd* is also hard float for 11.0-CURRENT.
> armv6*-*-freebsd is only hard float ABI for FreeBSD 11.

My understanding is that the older rpi's are ARM1176JZF-S, "which IS armv6" to quote Ian Lepore. I've not used such under 10.x at all so I may be making some implicit bad assumptions below. Feel free to correct my stupidities. . .

Unless 10.x FreeBSD is also switching to hardfloat I do not expect that the above part of your note is fully descriptive for compiler ports. (Presumes continued targeting of 10.x armv6 for rpi.)

armv6*-*-freebsd10* (such as for a 10.x rpi) is softfloat and stays that way in 10.x .

armv6*-*-freebsd11* (such as for a 11.x rpi or rpi2) is hardfloat now.

(I'm guessing those naming patterns.)

The compiler ports and their supporting runtime files deal with both targeting contexts for some amount of time (until 10.x can be dropped by ports). (Forms of on-the-fly code generation might also have such issues.)

>> Of course until everyone updates to modern enough armv6 context a mix of softfloat and hardfloat will be around.
> Are you saying that we need to get these changes to the ports in place
> to support hard float? Are you saying we need to support a mix better
> (which is unlikely to happen, btw, without a passionate champion)? Is
> there some other point I'm missing?
> Warner

A compiler toolchain in ports that targeted softfloat ABI before now needs to target the hardfloat ABI for 11.0 --and that apparently now uses "VFP register arguments".

gcc/crtbegin.o , gcc/crtend.o , and the like for hardfloat contexts need to handle at least "VFP register arguments" now but do not yet do so.

The old armv6*-*-freebsd* pattern used to identify a softfloat context and some text matching that pattern now identifies a hardfloat context ( armv6*-*-freebsd11* as far as I can tell). The toolchain example above is/was based on the pattern arm*hf-*-freebsd* to identify hardfloat vs. armv6*-*-freebsd* for softfloat (both 10.x and 11.0?). This is no longer sufficient.

Of course until someone rebuilds and installs replacing an older 11.0 build that had text matching the pattern armv6*-*-freebsd11*, the build it really is still softfloat so there is a transition-time issue because the text used does not uniquely identify the context: Once the ports they needed are ready folks then need to upgrade the 11.0 vintage to track. Before then the lack of ports might break their context if they update the 11.0 vintage. 

So I think the answer to the first question is: Yes there  are  changes that need to be made for the compiler ports to work for 11.0 and its hardfloat use. I'm guessing that building the ports for targeting 10.x is also to be possible for some time.

For the second question: hardfloat is not supported yet in ports. It needs to be for targeting armv6*-*-freebsd11* (11.0). Softfloat needs to be supported for targeting armv6*-*-freebsd10* (10.x). I do not see 11.0 supporting softfloat going forward. I do not see 10.x supporting hardfloat going forward. The relevant ports have 2 contexts to span unless 10.x ( armv6*-*-freebsd10* ) support is to be dropped now.

Am I clearer this time? (I leave the 3rd question to you: Did I make any new points here?)

Mark Millard
markmi at dsl-only.net

More information about the freebsd-ports mailing list