Patchwork PATCH: Correctly configure all big-endian ARM archs, not just arm*-*-linux-*.

login
register
mail settings
Submitter Seth LaForge
Date Feb. 15, 2013, 6:20 p.m.
Message ID <CAC_HCCN+Qzb7NQPaDXA4+jif4aWQv-epRvd73ueKJNoACh_WJA@mail.gmail.com>
Download mbox | patch
Permalink /patch/220797/
State New
Headers show

Comments

Seth LaForge - Feb. 15, 2013, 6:20 p.m.
Currently, for arm-* archs, TARGET_BIG_ENDIAN_DEFAULT is only set in
the case branch for arm*-*-linux-*, not for other arm architectures.
We're compiling for the TI TMS570, which is a big-endian processor,
with target set to armeb-unknown-eabi.  The following patch moves the
big-endian check out of the big architecture case, so that
TARGET_BIG_ENDIAN_DEFAULT is consistently set for any armeb-*-*
target.

We've been using this with good results for over a year at Google on
TMS570 processors.

This fixes bug 52187 - armeb-unknown-eabi not recognized as big-endian.

Seth LaForge


gcc/
        * config.gcc: Add TARGET_BIG_ENDIAN_DEFAULT=1 for all arm*b archs.

 	tm_file="$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h arm/arm.h"
 	# Define multilib configuration for arm-linux-androideabi.
Richard Earnshaw - Feb. 15, 2013, 6:28 p.m.
On 15/02/13 18:20, Seth LaForge wrote:
> Currently, for arm-* archs, TARGET_BIG_ENDIAN_DEFAULT is only set in
> the case branch for arm*-*-linux-*, not for other arm architectures.
> We're compiling for the TI TMS570, which is a big-endian processor,
> with target set to armeb-unknown-eabi.  The following patch moves the
> big-endian check out of the big architecture case, so that
> TARGET_BIG_ENDIAN_DEFAULT is consistently set for any armeb-*-*
> target.
>
> We've been using this with good results for over a year at Google on
> TMS570 processors.
>
> This fixes bug 52187 - armeb-unknown-eabi not recognized as big-endian.
>
> Seth LaForge
>
>
> gcc/
>          * config.gcc: Add TARGET_BIG_ENDIAN_DEFAULT=1 for all arm*b archs.
>
> diff -u -r gcc-4.8-20130210/gcc/config.gcc gcc-4.8-20130210.new/gcc/config.gcc
> --- gcc-4.8-20130210/gcc/config.gcc	2013-02-08 08:02:47.000000000 -0800
> +++ gcc-4.8-20130210.new/gcc/config.gcc	2013-02-14 16:37:14.282107219 -0800
> @@ -809,6 +809,13 @@
>     ;;
>   esac
>
> +# Handle big-endian ARM architectures.
> +case ${target} in
> +arm*b-*-*)
> +	tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
> +	;;

Not ok.  This would mismatch on

arm-blob-linux-gnueabi

and cause it to be treated as big-endian.

R.
Seth LaForge - Feb. 15, 2013, 6:33 p.m.
On Fri, Feb 15, 2013 at 10:28 AM, Richard Earnshaw <rearnsha@arm.com> wrote:
> On 15/02/13 18:20, Seth LaForge wrote:
>> +# Handle big-endian ARM architectures.
>> +case ${target} in
>> +arm*b-*-*)
>> +       tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
>> +       ;;
>
> Not ok.  This would mismatch on
>
> arm-blob-linux-gnueabi
>
> and cause it to be treated as big-endian.

I was under the impression that gcc target specs were always triplets;
there are certainly lots of references in the gcc docs to "gcc target
triplet".

Are there cases in which the target can have more than 3 components?
If so, I could certainly change the test to use a regexp, or inline it
all of the ARM handlers in the case statement below.

Seth
Richard Earnshaw - Feb. 15, 2013, 6:41 p.m.
On 15/02/13 18:33, Seth LaForge wrote:
> On Fri, Feb 15, 2013 at 10:28 AM, Richard Earnshaw <rearnsha@arm.com> wrote:
>> On 15/02/13 18:20, Seth LaForge wrote:
>>> +# Handle big-endian ARM architectures.
>>> +case ${target} in
>>> +arm*b-*-*)
>>> +       tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
>>> +       ;;
>>
>> Not ok.  This would mismatch on
>>
>> arm-blob-linux-gnueabi
>>
>> and cause it to be treated as big-endian.
>
> I was under the impression that gcc target specs were always triplets;
> there are certainly lots of references in the gcc docs to "gcc target
> triplet".

They haven't been strict triplets for a long time now.  In fact, ever 
since somebody decided that linux wasn't enough and that gnu had to be 
mentioned as well... :-(

>
> Are there cases in which the target can have more than 3 components?
> If so, I could certainly change the test to use a regexp, or inline it
> all of the ARM handlers in the case statement below.
>
> Seth
>

Yes, anything with linux in it will now be a quadruplet.  There may be 
other cases as well.  Once a rule has been broken for one case, you can 
hardly enforce it against others.  The rot has set in...

R.
Mike Stump - Feb. 15, 2013, 10:37 p.m.
On Feb 15, 2013, at 10:33 AM, Seth LaForge <sethml@google.com> wrote:
> I was under the impression that gcc target specs were always triplets;

:-)  arm-elf is a target spec, as is i960.  There is a canonicalization that takes place that can change the format of it to be more standardized.  One or more characters is the official guideline, assuming more, would be wrong.  We often talk about target triplets, as a triplet is what one gets after canonicalization, usually.

> there are certainly lots of references in the gcc docs to "gcc target
> triplet".

Well, the doc misled you.  When it speaks of the target triplet, what it means is the target spec.  The target spec is 1 or more characters.  Now, as luck would have if, no one seems daring to run off with 1 character just yet, but, they in theory can.  2 is the current lower bound limit on spec, for example, mt.  Most of the software only deals with canonicalized target specs.  The are in the canonical form.  That's all we can say about that.  It has a generalized form that most specs will usually follow.  For example, basiccputype-vendorofhardware-typeofoperatingsystem is a general format that most systems use, as we recommend it, first for new specs.  Simple, straightforward.

> Are there cases in which the target can have more than 3 components?

Answering this question doesn't serve you, or us.  You get to play, with the specs you play with.  If you own foo, you can decree that foo-bar-bee-bar is the canonical, and that the canonical always has 4 components, or not.  Or maybe 5.  Or maybe 3.  If you don't own it, you don't get to.  For example, the linux specs were decreed that they would be linux-gnu in the canonical spec.  This bumps any spec that uses -linux to be one more component than the spec it started with, so if it started with the usual 3, would then become 4 after the rule change.

Now, for the concrete.  In arm land, you want armeb-*, armbe-*, armv[345]b-* and xscaleeb-*.  This is derivable from the config.sub file.  (crossing fingers that be means big endian) You explicitly don't want any other form, as no other form works.
aldot - Feb. 16, 2013, 3:45 p.m.
On 15 February 2013 19:28:29 Richard Earnshaw <rearnsha@arm.com> wrote:
> On 15/02/13 18:20, Seth LaForge wrote:
> > Currently, for arm-* archs, TARGET_BIG_ENDIAN_DEFAULT is only set in
> > the case branch for arm*-*-linux-*, not for other arm architectures.
> > We're compiling for the TI TMS570, which is a big-endian processor,
> > with target set to armeb-unknown-eabi.  The following patch moves the
> > big-endian check out of the big architecture case, so that
> > TARGET_BIG_ENDIAN_DEFAULT is consistently set for any armeb-*-*
> > target.
> >
> > We've been using this with good results for over a year at Google on
> > TMS570 processors.
> >
> > This fixes bug 52187 - armeb-unknown-eabi not recognized as big-endian.
> >
> > Seth LaForge
> >
> >
> > gcc/
> >          * config.gcc: Add TARGET_BIG_ENDIAN_DEFAULT=1 for all arm*b archs.
> >
> > diff -u -r gcc-4.8-20130210/gcc/config.gcc 
> gcc-4.8-20130210.new/gcc/config.gcc
> > --- gcc-4.8-20130210/gcc/config.gcc	2013-02-08 08:02:47.000000000 -0800
> > +++ gcc-4.8-20130210.new/gcc/config.gcc	2013-02-14 16:37:14.282107219 -0800
> > @@ -809,6 +809,13 @@
> >     ;;
> >   esac
> >
> > +# Handle big-endian ARM architectures.
> > +case ${target} in
> > +arm*b-*-*)
> > +	tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
> > +	;;
>
> Not ok.  This would mismatch on
>
> arm-blob-linux-gnueabi
>
> and cause it to be treated as big-endian.

Sounds like a DUP of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
Is the missing hunk in by now (cannot look myself right now)?
Thanks,
>
> R.
>
>


Sent with AquaMail for Android
http://www.aqua-mail.com
Seth LaForge - Feb. 20, 2013, 11:28 p.m.
On Sat, Feb 16, 2013 at 7:45 AM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> Sounds like a DUP of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
> Is the missing hunk in by now (cannot look myself right now)?

The commit you describe appears to be in trunk but not in gcc-4_7-branch.

I don't think the problem described in that bug is not a duplicate of
my problem - for gcc-4.8-20130210 (which includes that change) I have
to add my TARGET_BIG_ENDIAN_DEFAULT=1 change to make building for my
processor work, and gcc-4.7.2 also works for my processor using my
patch.

Seth

Patch

diff -u -r gcc-4.8-20130210/gcc/config.gcc gcc-4.8-20130210.new/gcc/config.gcc
--- gcc-4.8-20130210/gcc/config.gcc	2013-02-08 08:02:47.000000000 -0800
+++ gcc-4.8-20130210.new/gcc/config.gcc	2013-02-14 16:37:14.282107219 -0800
@@ -809,6 +809,13 @@ 
   ;;
 esac

+# Handle big-endian ARM architectures.
+case ${target} in
+arm*b-*-*)
+	tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
+	;;
+esac
+
 case ${target} in
 aarch64*-*-elf)
 	tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h"
@@ -867,11 +874,6 @@ 
 	;;
 arm*-*-linux-*)			# ARM GNU/Linux with ELF
 	tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
-	case $target in
-	arm*b-*-linux*)
-	    tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
-	    ;;
-	esac
 	tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi
arm/t-linux-eabi"