Date: Thu, 28 Feb 2013 07:51:25 +1300 From: Andrew Turner <andrew@fubar.geek.nz> To: Tim Kientzle <tim@kientzle.com> Cc: Brooks Davis <brooks@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: ARM EABI directions Message-ID: <20130228075125.3e037bc4@bender> In-Reply-To: <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <C8B590D8-70D2-41DB-812B-859C0F20F765@kientzle.com> <EE066522-388C-45C4-8DB7-E2C7BBB60D69@bsdimp.com> <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Feb 2013 09:09:15 -0800
Tim Kientzle <tim@kientzle.com> wrote:
> >>
> >>>> +.if ${TARGET_ARCH} != ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE}
> >>>> == "clang" +.if (${TARGET_ARCH} == "arm" || ${TARGET_ARCH} ==
> >>>> "armv6") && \ +${MK_ARM_EABI} != "no"
> >>>> +TARGET_ABI= gnueabi
> >>>> +.else
> >>>> +TARGET_ABI= unknown
> >>>> +.endif
> >>>
> >>> We need to fix the gnueabi issue with arm. machine_arch should
> >>> always be enough to be self-hosting, and while I fixed the armv6
> >>> issue, this has cropped up in its place :(.
> >>
> >> Personally, I would like to see us switch to gnueabi
> >> entirely and drop the configuration options.
> >
> > Me too, but that would mean breaking 9.x binaries on 10.x systems,
> > so some thought must be exercised here.
It also breaks for people doing native builds. In this case I'm
planning on providing a bootstrap tarball.
> Why? ARM was Tier 2 for FreeBSD 9.x, and the FreeBSD
> package builds still don't support ARM packages, so I'm
> not convinced that would be a problem.
>
> OTOH, I'm hoping we can get ARM to Tier 1 for 10.x, so
> this will be a concern after that point.
This is why I'm trying to finish of this support and get it tested &
enabled by default.
> > My preference would be to support building eabi binaries only, but
> > have a kernel option that would allow execution of oabi binaries.
>
> That would make sense. ISTR a thread discussing whether
> it was possible to transparently support both eabi and oabi
> syscalls.
It is possible, I just never finished the code, and am unlikely to as
it would hold back other work.
> > Then again, we are also heading to the soft fp vs vfp issue too…
>
> <sigh> Yeah.
While vfp is optional on ARMv6 & v7 almost all SoCs have it, I don't
know of any that are missing it. I'm planning on making EABI with
Hard-Float the default on armv6. All the armv6 cores we support have
some level of VFP support in them. As floating-point values are passed
in using the VFP registers the hard-float code will fail on chips
without the VFP unit. If someone finds one that is missing it we
could add a new TARGET_ARCH to build without vfp.
Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130228075125.3e037bc4>