From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 18:51:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66934380; Wed, 27 Feb 2013 18:51:59 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 3477F7E7; Wed, 27 Feb 2013 18:51:58 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MIW002WG72FVF40@smtp4.clear.net.nz>; Thu, 28 Feb 2013 07:51:52 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Thu, 28 Feb 2013 07:51:51 +1300 Date: Thu, 28 Feb 2013 07:51:25 +1300 From: Andrew Turner Subject: Re: ARM EABI directions In-reply-to: <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com> To: Tim Kientzle Message-id: <20130228075125.3e037bc4@bender> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 8BIT References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com> Cc: Brooks Davis , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:51:59 -0000 On Wed, 27 Feb 2013 09:09:15 -0800 Tim Kientzle 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… > > 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