Date: Sat, 28 May 2016 23:00:39 -0700 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: Gerald Pfeifer <gerald@freebsd.org>, Brooks Davis <brooks@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float) Message-ID: <93022D2B-29D1-4422-A7B0-5366C0182973@dsl-only.net> In-Reply-To: <CANCZdfq37CioLHzewwhtp%2BODku=rSGJkvVKxfVV9Kd6VRg__JA@mail.gmail.com> References: <1E66E56C-E615-4180-A3F2-E8E48E26B6CD@dsl-only.net> <CANCZdfq37CioLHzewwhtp%2BODku=rSGJkvVKxfVV9Kd6VRg__JA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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) >>=20 >> 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 >>=20 >> The first (013931.html) shows that xgcc for configure:3686 for = contest.c ends up with the likes of: >>=20 >> /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 >>=20 >> and points to gcc/config.gcc only having = TARGET_FREEBSD_ARM_HARD_FLOAT=3D1 for arm*hf-*-freebsd* . But now = armv6*-*-freebsd* is also hard float for 11.0-CURRENT. >=20 > 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. >=20 > 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? >=20 > 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.=20 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?) =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93022D2B-29D1-4422-A7B0-5366C0182973>