So, turns out that on arm the --with-arch= isn't used, so the compiler compiles stuff for the default CPU unless you add -march. This makes the use of differents CHOSTs/CTARGETs useless. There are some caveats, though: armv7* won't work as of gcc-4.3.3, since the support for that cpu hasn't been merged to the gcc-4.3 branch -> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37912 But when it gets merged, valid values will be `armv7', `armv7-a', `armv7-r' and `armv7-m'. The dashes will give some issues, i guess? Also 'b' and 'l' will need to be ignored, from armv5tel and armv5teb. The way to reproduce it: echo | armv5tel-softfloat-linux-gnueabi-gcc -dM -E - | grep __ARM #define __ARMEL__ 1 #define __ARM_ARCH_4T__ 1 #define __ARM_EABI__ 1 echo | armv5tel-softfloat-linux-gnueabi-gcc -march=armv5te -dM -E - | grep __ARM #define __ARMEL__ 1 #define __ARM_ARCH_5TE__ 1 #define __ARM_EABI__ 1 This also happens on old abi: echo | armv4l-unknown-linux-gnu-gcc -dM -E - | grep __ARM #define __ARMEL__ 1 #define __ARM_ARCH_3__ 1 echo | armv4l-unknown-linux-gnu-gcc -march=armv4 -dM -E - | grep __ARM #define __ARMEL__ 1 #define __ARM_ARCH_4__ 1
echo | armv7a-softfloat-linux-gnueabi-gcc -march=armv7-r -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -dM -E - | grep __ARM #define __ARMEL__ 1 #define __ARM_NEON__ 1 #define __ARM_ARCH_7A__ 1 #define __ARM_EABI__ 1 --- 7a is valid 7r is valid. 7m not valid. armv7a-softfloat-linux-gnueabi-gcc -v 2>&1 | tail -n 1 gcc version 4.3.2 (Gentoo 4.3.2 p1.2)
Something went wrong with my paste.. But 7r -> #define __ARM_ARCH_7R__
what you're describing is the proper operation of gcc by design and for every architecture. and no, it doesnt make CHOST/CTARGET useless in any way whatsoever. about the only thing that could be added to toolchain.eclass is: --with-arch=${CTARGET%%-*} if that isnt sufficient, then too bad :p
--with-arch=${CTARGET%%-*} wont work. It would need to be a proper mapping.
Someone please come up with the mappings then, and, preferably, a patch to the eclass for review. Atleast the mappings will be a good first step so we have some idea of how complicated this could become.
Created attachment 214864 [details, diff] toolchain.patch Here's a patch for review :) I'll explain: Since armv7, the -march values are armv7-a, armv7-m, armv7-r...etc, so obviously using the CTARGET thing won't work. Mainly because the CHOSTs are armv7a, armv7m...so it would try --with-arch=armv7a, which won't work. Thats why on the case of armv7-{something}, i replace armv7 with armv7-
Comment on attachment 214864 [details, diff] toolchain.patch This patch wouldn't work for armv4l, armv4tl and armv5tel...iow, the ones that have l or eb which specify the endian.
Created attachment 216013 [details, diff] toolchain.patch This should fix it. Enhancements welcome :)
Hello, this breaks for me on armv5tejl-softfloat-linux-gnueabi. I added [[ ${arm_arch} == armv5tej ]] && arm_arch=${arm_arch%j} but I guess, a more generic solution is in order. /proc/cpuinfo of my Linkstation Pro (Marvell Orion) has: CPU architecture: 5TEJ My SheevaPlug has got: CPU architecture: 5TE So it seems, TEJ is a distinct arch but GCC doesn't know it yet. -- bye, Micha
(In reply to comment #9) > Hello, > > this breaks for me on armv5tejl-softfloat-linux-gnueabi. You should be using v5tel- vs v5tejl- @ Gentoo.
perhaps, but this --with-arch= seems flakier than it should be. it should figure out what values are valid from the source and only pass --with-arch if it can find a match.
(In reply to comment #11) > perhaps, but this --with-arch= seems flakier than it should be. it should > figure out what values are valid from the source and only pass --with-arch if > it can find a match. > Yeah that might be best seeing how much feedback we have seen.
*** Bug 308093 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > > this breaks for me on armv5tejl-softfloat-linux-gnueabi. > You should be using v5tel- vs v5tejl- @ Gentoo. A recursive, case-insensitive grep for 5tej in the gcc sources produces multiple hits, most notably: gcc/config/arm/arm-cores.def:ARM_CORE("arm926ej-s", arm926ejs, 5TEJ, FL_LDSCHED, 9e) gcc/config/arm/arm.c:#define FL_FOR_ARCH5TEJ FL_FOR_ARCH5TE gcc/config/arm/lib1funcs.asm: || defined __ARM_ARCH_5TE__ || defined __ARM_ARCH_5TEJ__ \ For now it seems that 5TEJ is treated the same as 5TE, but this could change. And then gcc would most likely accept a --with-arch=armv5tej configure option. So wouldn't armv5tejl-softfloat-linux-gnueabi be a valid arch specifier? Rationale: My CPU is identified as "CPU architecture: 5TEJ, CPU part: 0x926" in /proc/cpuinfo. Since I bootstrapped my system with a cross compiler from scratch, I used a platform triplet that most closely reflects my platform. I also have "-mcpu=arm926ej-s" in my CFLAGS already. So actually I'd much more like to have a --with-cpu=arm926ej-s passed to configure instead of any --with-arch option. More generic argument: I've always understood, that the platform triplet is mostly meant as just an identifier string. configure scripts interpreted it in the most robust and generic of ways to adjust their behaviour to the target platform. To use it to configure the kind of code the compiler produces by default, seems fragile to me. If not, why would gcc's configure have --with-arch and --with-cpu options in the first place and not just parse the platform triplet? Couldn't we have a use flag instead, that enables a function which looks for -march and -mcpu switches in CFLAGS and passes their value to the --with-arch and --with-cpu configure options?
(In reply to comment #14) > So wouldn't armv5tejl-softfloat-linux-gnueabi be a valid arch specifier? Thing is that TEJ vs TE provides nothing on linux, just Jazelle stuff. > > Rationale: My CPU is identified as "CPU architecture: 5TEJ, CPU part: 0x926" in > /proc/cpuinfo. Since I bootstrapped my system with a cross compiler from > scratch, I used a platform triplet that most closely reflects my platform. I > also have "-mcpu=arm926ej-s" in my CFLAGS already. So actually I'd much more > like to have a --with-cpu=arm926ej-s passed to configure instead of any > --with-arch option. This just follows the idea of other arches. On x86, i686-pc-linux... = -march=i686. The CHOST provides an (sub-)architecture name, not a CPU name, therefore thats why its -march and not -mcpu. > > More generic argument: I've always understood, that the platform triplet is > mostly meant as just an identifier string. configure scripts interpreted it in > the most robust and generic of ways to adjust their behaviour to the target > platform. To use it to configure the kind of code the compiler produces by > default, seems fragile to me. If not, why would gcc's configure have > --with-arch and --with-cpu options in the first place and not just parse the > platform triplet? Again, this happens on x86, sh and alpha. Why its not the case on arm? No clue, distros use arm-unknown... but we don't. In the case of Ubuntu, the CHOST is arm-unkn... but they do --with-arch=armv7-a. Why do you want to use an armv5te* CHOST, if it does exactly the same by default as arm-? > > Couldn't we have a use flag instead, that enables a function which looks for > -march and -mcpu switches in CFLAGS and passes their value to the --with-arch > and --with-cpu configure options? > If you don't want this kind of thing, then you should change to arm-...
(In reply to comment #15) > > So wouldn't armv5tejl-softfloat-linux-gnueabi be a valid arch specifier? > Thing is that TEJ vs TE provides nothing on linux, just Jazelle stuff. It might be a noop or alias, but it's not illegal. So IMO it should be accepted without error. > This just follows the idea of other arches. On x86, i686-pc-linux... = > -march=i686. The CHOST provides an (sub-)architecture name, not a CPU name, > therefore thats why its -march and not -mcpu. Ah well, generally, just because someone else does it shouldn't be the only reason to do it also, should it? With regard to your example: gcc's configure accepts i[34567]86-*-*, but -march doesn't accept i786. So while gcc accepts to be built on i786-unknown-linux-foo the ebuild will fail because configure will be fed --with-arch=i786. You're putting meaning into something that's not meant to reliably carry that meaning. > Again, this happens on x86, sh and alpha. Why its not the case on arm? No clue, > distros use arm-unknown... but we don't. In the case of Ubuntu, the CHOST is > arm-unkn... but they do --with-arch=armv7-a. It's because the platform triplet is mostly an identifier and doesn't necessarily have anyhing to do with what code my compiler outputs by default, what colour the Gnome background is or most anything else. > Why do you want to use an armv5te* CHOST, if it does exactly the same by > default as arm-? That's not what I said. Primarily I'd like gcc to build without error on my armv5tejl-softfloat-linux-gnueabi. I see the benefit in building gcc with --with-arch or even --with-cpu. But I wonder if the source for their value is particularly well chosen. I'd also very much like to have my compiler built with --with-cpu=arm926ej-s. This can't be done with the current implementation.
i already said in comment #11 that we're going to change things to only use --with-arch if the value can be validated. if you want to debate random chost values, take it elsewhere. it isnt relevant to this bug.
Created attachment 228299 [details, diff] toolchainv3.patch Something like this, maybe?
*** Bug 413545 has been marked as a duplicate of this bug. ***
i've reworked things so that it sources the config.gcc with values to see if the requested arch is valid. if it isn't, we don't bother setting a default --with-arch flag at all. http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.533&r2=1.534
