| Message ID | CAC_HCCN+Qzb7NQPaDXA4+jif4aWQv-epRvd73ueKJNoACh_WJA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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.
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
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.
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.
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
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
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"
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.