From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH] ARM: refine compiler target architecture Date: Wed, 18 Dec 2013 10:01:56 +0100 Message-ID: <52B16484.9010006@linaro.org> References: <1387272871-2341-1-git-send-email-andre.przywara@linaro.org> <1387275661.27441.34.camel@kazak.uk.xensource.com> <52B1533A.30803@linaro.org> <1387355361.1025.40.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VtD1O-0007YE-4D for xen-devel@lists.xenproject.org; Wed, 18 Dec 2013 09:02:26 +0000 Received: by mail-bk0-f45.google.com with SMTP id mx13so92276bkb.32 for ; Wed, 18 Dec 2013 01:02:24 -0800 (PST) In-Reply-To: <1387355361.1025.40.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, julien.grall@linaro.org, patches@linaro.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 12/18/2013 09:29 AM, Ian Campbell wrote: > On Wed, 2013-12-18 at 08:48 +0100, Andre Przywara wrote: >> But actually the ABI is orthogonal to the -march setting, right? AFAIK >> -march just controls which instruction the compiler emits and which >> instructions the assembler allows. > > I thought they were subtly intertwined, even if technically they are > orthogonal. eek. > >> $ arm-linux-gnueabi-gcc -v >> Target: arm-linux-gnueabi >> ... --with-arch=armv4t ... >> >> This is pretty conservative, but the compiler is fine and with >> -march=armv7-a -mfloat-abi=hard it even generates modern code. > > I think we can't force float-abi=hard unless the rest of the libraries > on the system use it? Which won't be the case on armel. Right. Well, we can force it, but it will not work ;-) Not sure if it even links. >> Are there really people out there still using OABI? > > I thought the Debian armel port was OABI, it seems I was mistaken, > sorry. From the native Debian armel compiler: > > $ gcc -v > [...] > Target: arm-linux-gnueabi > Configured with: [...] > --with-arch=armv4t --with-float=soft --enable-checking=release > --build=arm-linux-gnueabi --host=arm-linux-gnueabi > --target=arm-linux-gnueabi > [...] > gcc version 4.8.2 (Debian 4.8.2-7) > > https://wiki.debian.org/ArmEabiPort confirms that I was wrong. > > The armhf port is EABI and v7: > $ gcc -v > [...] > Target: arm-linux-gnueabihf > Configured with: [...] > --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard > --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf > --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf > [...] > gcc version 4.6.3 (Debian 4.6.3-14) > >> Do we care? > > I care about people not getting confused into think that things will > work on such systems when it will not. The bugs resulting from an OABI > vs EABI mismatch will likely be quite subtle. > > I guess this means the original Debian arm (not -el nor -hf) port which > I suppose people are less likely to have these days. Right, this matches my quick research. armel should work, arm not. >> Both compilers I tested (Slackware and Debian cross) are purely EABI, >> but have less than armv7 as their default. > > I wonder if we can either add some option which will force EABI and > therefore fail to build on an OABI system (maybe march v7 is that test > given the age of OABI?) or add a configure check for struct alignment? Right, that sounds like a good thing. If I can find some time still this week, I can try to come up with something. > In any case looking back to the original patch I am now convinced that > it would be OK. I'm not sure about for 4.4 though, I'm a bit wary of > changing compiler defaults at this stage. I agree. Lets push it out for 4.5. I can write an email with the error message I got, the explanation and the fix to the list to help people with this problem meanwhile. Google should pick it up from the archives then ;-) Regards, Andre.