Date: Wed, 27 Feb 2013 09:54:23 -0700 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <tim@kientzle.com> Cc: Brooks Davis <brooks@freebsd.org>, freebsd-arch@freebsd.org Subject: ARM EABI directions Message-ID: <EE066522-388C-45C4-8DB7-E2C7BBB60D69@bsdimp.com> In-Reply-To: <C8B590D8-70D2-41DB-812B-859C0F20F765@kientzle.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <C8B590D8-70D2-41DB-812B-859C0F20F765@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 27, 2013, at 9:30 AM, Tim Kientzle wrote:
>=20
> On Feb 27, 2013, at 7:57 AM, Warner Losh wrote:
>=20
>>> +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} =
=3D=3D "clang"
>>> +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") =
&& \
>>> +${MK_ARM_EABI} !=3D "no"
>>> +TARGET_ABI=3D gnueabi
>>> +.else
>>> +TARGET_ABI=3D unknown
>>> +.endif
>>=20
>> 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 :(.
>=20
> 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.
My preference would be to support building eabi binaries only, but have =
a kernel option that would allow execution of oabi binaries.
Then again, we are also heading to the soft fp vs vfp issue too...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE066522-388C-45C4-8DB7-E2C7BBB60D69>