Hi All, After downloading linaro toolchain by apt-get in ubuntu, I compiled the uboot for ARM1136 SoC with -march=armv5 option. And it can compile successfully. Then I let the uboot run on target boards and system failed due to "undefined instructions". Checked linaro toolchain options, it is:
#arm-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1)
The imporant options are "--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16". I just want to ask whether these options stop arm-linux-gnueabi-gcc to support old arch? If so, according to gcc documents at http://gcc.gnu.org/install/configure.html,
"
--with-cpu=cpu --with-cpu-32=cpu --with-cpu-64=cpu Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC. --with-schedule=cpu --with-arch=cpu --with-arch-32=cpu --with-arch-64=cpu --with-tune=cpu --with-tune-32=cpu --with-tune-64=cpu --with-abi=abi --with-fpu=type --with-float=type These configure options provide default values for the -mschedule=, -march=, -mtune=, -mabi=, and -mfpu= options and for -mhard-float or -msoft-float. As with --with-cpu, which switches will be accepted and acceptable values of the arguments depend on the target. "
There are only default values for later compiling. Users should be able to swith to other values by setting other options. But why did arm-linux-gnueabi-gcc still build "undefined instructions" to arm1136 with "arch=armv5"? In fact arm1136 is armv6.
Then i compiled a toolchain for linaro gcc-linaro-4.4-2011.02-0 codes by myself, the options are simple:
#arm-none-linux-gnueabi-gcc -v Using built-in specs. Target: arm-none-linux-gnueabi Configured with: ../gcc-linaro-4.4-2011.02-0/configure --target=arm-none-linux-gnueabi --prefix=/home/vmuser/development/toolchain/build-toolchain/tools --enable-languages=c,c++ --disable-libgomp Thread model: posix gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0)
Then I compiled uboot by this toolchain again, the uboot can work. Then why can the toolchain compiled by myself support more arch? And what performance is lost in my compiling?
Thanks Barry
Hi Barry. GCC can be switched at runtime by supplying -march=* and/or -mcpu=* flags to the compiler, just as you have done below. The '--with-arch=*' lines you see below set what GCC compiles to by default.
Does your chip have a FPU? If not, it's probably the --with-fpu=vfpv3-d16 line that's causing you trouble. Give: gcc -march=armv5te -mfloat-abi=soft -marm
a try and see if that fixes the problem.
-- Michael
On Thu, Mar 24, 2011 at 2:57 PM, Barry Song 21cnbao@gmail.com wrote:
Hi All, After downloading linaro toolchain by apt-get in ubuntu, I compiled the uboot for ARM1136 SoC with -march=armv5 option. And it can compile successfully. Then I let the uboot run on target boards and system failed due to "undefined instructions". Checked linaro toolchain options, it is:
#arm-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1)
The imporant options are "--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16". I just want to ask whether these options stop arm-linux-gnueabi-gcc to support old arch? If so, according to gcc documents at http://gcc.gnu.org/install/configure.html,
"
--with-cpu=cpu --with-cpu-32=cpu --with-cpu-64=cpu Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC. --with-schedule=cpu --with-arch=cpu --with-arch-32=cpu --with-arch-64=cpu --with-tune=cpu --with-tune-32=cpu --with-tune-64=cpu --with-abi=abi --with-fpu=type --with-float=type These configure options provide default values for the -mschedule=, -march=, -mtune=, -mabi=, and -mfpu= options and for -mhard-float or -msoft-float. As with --with-cpu, which switches will be accepted and acceptable values of the arguments depend on the target. "
There are only default values for later compiling. Users should be able to swith to other values by setting other options. But why did arm-linux-gnueabi-gcc still build "undefined instructions" to arm1136 with "arch=armv5"? In fact arm1136 is armv6.
Then i compiled a toolchain for linaro gcc-linaro-4.4-2011.02-0 codes by myself, the options are simple:
#arm-none-linux-gnueabi-gcc -v Using built-in specs. Target: arm-none-linux-gnueabi Configured with: ../gcc-linaro-4.4-2011.02-0/configure --target=arm-none-linux-gnueabi --prefix=/home/vmuser/development/toolchain/build-toolchain/tools --enable-languages=c,c++ --disable-libgomp Thread model: posix gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0)
Then I compiled uboot by this toolchain again, the uboot can work. Then why can the toolchain compiled by myself support more arch? And what performance is lost in my compiling?
Thanks Barry
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 24/03/11 03:09, Michael Hope wrote:
Hi Barry. GCC can be switched at runtime by supplying -march=* and/or -mcpu=* flags to the compiler, just as you have done below. The '--with-arch=*' lines you see below set what GCC compiles to by default.
While that is true, but the libraries that come with the compiler are probably still inappropriate for older architectures.
The short answer is that, no, the Linaro *binary* releases will not support -march=armv5.
However, you can build your own compiler from the Linaro sources, and then build the libraries you need to match, and you can have v5 support. This is not a straightforward process. :(
If you'd prefer not to build your own tools, may I recommend CodeSourcery's Sourcery G++ Lite for ARM GNU/Linux:
http://www.codesourcery.com/sgpp/lite/arm
That compiler defaults to ARMv5TE. If that's too new, the toolchain also contains prebuilt libraries for ARMv4T (-march=armv4t) and those should be compatible. Although it is not the Linaro compiler, it is somewhat similar, and programs you build should be compatible with Ubuntu. (Disclosure: I work for CodeSourcery).
Hope that helps
Andrew
On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs andrew.stubbs@linaro.org wrote:
The short answer is that, no, the Linaro *binary* releases will not support -march=armv5.
However, you can build your own compiler from the Linaro sources, and then build the libraries you need to match, and you can have v5 support. This is not a straightforward process. :(
You can always use the OpenWrt buildroot to easily build a custom Linaro-based crosscompiler, just make sure you select the right libc for your needs (we use uClibc by default) and a target similar to yours.
Imre
On 24/03/11 11:05, Imre Kaloz wrote:
On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs andrew.stubbs@linaro.org wrote:
However, you can build your own compiler from the Linaro sources, and then build the libraries you need to match, and you can have v5 support. This is not a straightforward process. :(
You can always use the OpenWrt buildroot to easily build a custom Linaro-based crosscompiler, just make sure you select the right libc for your needs (we use uClibc by default) and a target similar to yours.
Or OpenEmbedded or CrossTool / CrossTool-NG.
Andrew
2011/3/24 Andrew Stubbs andrew.stubbs@linaro.org
On 24/03/11 11:05, Imre Kaloz wrote:
On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs andrew.stubbs@linaro.org wrote:
However, you can build your own compiler from the Linaro sources, and then build the libraries you need to match, and you can have v5 support. This is not a straightforward process. :(
You can always use the OpenWrt buildroot to easily build a custom Linaro-based crosscompiler, just make sure you select the right libc for your needs (we use uClibc by default) and a target similar to yours.
Or OpenEmbedded or CrossTool / CrossTool-NG.
Thank all of you! you really help me much! You toolchain team is really great!
In fact, i knew how to compile a toolchain. As i said, i have compiled a toolchain by simple options: Configured with: ../gcc-linaro-4.4-2011.02-0/ configure --target=arm-none-linux-gnueabi --prefix=/home/vmuser/development/toolchain/build-toolchain/tools --enable-languages=c,c++ --disable-libgomp Thread model: posix gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0)
it can make uboot work with arch=armv5.
i want to know whether any performance is lost by my simple configure options if the toolchain is used to armv7 with vfpv3? GCC documents show that those options we use to compile gcc will become the default options of gcc runtime. But what is the real benefit toolchains can get by configuring gcc with default arch and fpu since we can switch arch options at runtime?
Is the key glibc? If compiling glibc by gcc with options for a special ARM arch and float point unit, it will improve the performance of glibc to the arch? And then the glibc will not support other arch or SoCs without the specified float point unit?
Andrew
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Fri, Mar 25, 2011 at 2:59 AM, Barry Song 21cnbao@gmail.com wrote:
2011/3/24 Andrew Stubbs andrew.stubbs@linaro.org
On 24/03/11 11:05, Imre Kaloz wrote:
On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs andrew.stubbs@linaro.org wrote:
However, you can build your own compiler from the Linaro sources, and then build the libraries you need to match, and you can have v5 support. This is not a straightforward process. :(
You can always use the OpenWrt buildroot to easily build a custom Linaro-based crosscompiler, just make sure you select the right libc for your needs (we use uClibc by default) and a target similar to yours.
Or OpenEmbedded or CrossTool / CrossTool-NG.
Thank all of you! you really help me much! You toolchain team is really great!
In fact, i knew how to compile a toolchain. As i said, i have compiled a toolchain by simple options: Configured with: ../gcc-linaro-4.4-2011.02-0/ configure --target=arm-none-linux-gnueabi --prefix=/home/vmuser/development/toolchain/build-toolchain/tools --enable-languages=c,c++ --disable-libgomp Thread model: posix gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0)
it can make uboot work with arch=armv5.
i want to know whether any performance is lost by my simple configure options if the toolchain is used to armv7 with vfpv3? GCC documents show that those options we use to compile gcc will become the default options of gcc runtime. But what is the real benefit toolchains can get by configuring gcc with default arch and fpu since we can switch arch options at runtime?
Is the key glibc? If compiling glibc by gcc with options for a special ARM arch and float point unit, it will improve the performance of glibc to the arch? And then the glibc will not support other arch or SoCs without the specified float point unit?
Hi Barry. The short answer is 'it depends' :)
GCC is more than a compiler and includes other things such as a runtime library (libgcc) and hooks into the libc for features like thread local storage. These are built for the architecture and floating point unit options you pass to GCC's configure, so if you want one toolchain that runs everywhere then you need to configure it for the lowest common denominator (normally a ARMv5T in ARM mode with no FPU). A similar argument applies to GLIBC.
The next question is, does this matter for your application? What workload will your product run and will it be meaningfully affected by this lowest common denominator build? * If your application uses a lot of floating point, then the lack of FPU support in GLIBC matters * If your product has limited memory, then the smaller code size of Thumb-2 is worthwhile * If you need to squeeze out another 5 % in performance, then using ARMv7 instead of ARMv5 will help
There are other technical solutions such as: * Building libgcc and glibc for the different variants and picking the best at link time * Building them and picking at dynamic link time using hwcaps or similar
These make sense for a generic binary toolchain such as the CodeSourcery one Andrew mentioned, and for generic distributions such as Ubuntu but not for a focused end user product.
-- Michael
2011/3/24 Michael Hope michael.hope@linaro.org:
On Fri, Mar 25, 2011 at 2:59 AM, Barry Song 21cnbao@gmail.com wrote:
2011/3/24 Andrew Stubbs andrew.stubbs@linaro.org
On 24/03/11 11:05, Imre Kaloz wrote:
On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs andrew.stubbs@linaro.org wrote:
However, you can build your own compiler from the Linaro sources, and then build the libraries you need to match, and you can have v5 support. This is not a straightforward process. :(
You can always use the OpenWrt buildroot to easily build a custom Linaro-based crosscompiler, just make sure you select the right libc for your needs (we use uClibc by default) and a target similar to yours.
Or OpenEmbedded or CrossTool / CrossTool-NG.
Thank all of you! you really help me much! You toolchain team is really great!
In fact, i knew how to compile a toolchain. As i said, i have compiled a toolchain by simple options: Configured with: ../gcc-linaro-4.4-2011.02-0/ configure --target=arm-none-linux-gnueabi --prefix=/home/vmuser/development/toolchain/build-toolchain/tools --enable-languages=c,c++ --disable-libgomp Thread model: posix gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0)
it can make uboot work with arch=armv5.
i want to know whether any performance is lost by my simple configure options if the toolchain is used to armv7 with vfpv3? GCC documents show that those options we use to compile gcc will become the default options of gcc runtime. But what is the real benefit toolchains can get by configuring gcc with default arch and fpu since we can switch arch options at runtime?
Is the key glibc? If compiling glibc by gcc with options for a special ARM arch and float point unit, it will improve the performance of glibc to the arch? And then the glibc will not support other arch or SoCs without the specified float point unit?
Hi Barry. The short answer is 'it depends' :)
GCC is more than a compiler and includes other things such as a runtime library (libgcc) and hooks into the libc for features like thread local storage. These are built for the architecture and floating point unit options you pass to GCC's configure, so if you want one toolchain that runs everywhere then you need to configure it for the lowest common denominator (normally a ARMv5T in ARM mode with no FPU). A similar argument applies to GLIBC.
The next question is, does this matter for your application? What workload will your product run and will it be meaningfully affected by this lowest common denominator build? * If your application uses a lot of floating point, then the lack of FPU support in GLIBC matters
Completely right. I got a linaro 4.5 by:
sudo add-apt-repository ppa:linaro-maintainers/toolchain sudo apt-get update sudo apt-get install gcc-4.5-arm-linux-gnueabi
Then I did WHETSTONE benchmark on a low-frequency cortex A9 FPGA with vfpv3.
Result showed linaro by apt-get is using generic glibc in fact. its gave only 3.3 WHETSTONE MIPS. Then i compiled a glibc with vfpv3 support to replace the glibc by apt-get, the new toolchain gave 16.7 WHETSTONE MIPS, 400% improvement in WHETSTONE.
* If your product has limited memory, then the smaller code size of Thumb-2 is worthwhile * If you need to squeeze out another 5 % in performance, then using ARMv7 instead of ARMv5 will help
Completely right. I did a edn benchmark from http://www.mrtc.mdh.se/projects/wcet/wcet_bench/edn/edn.c. EDN can show memory and fixed-point performance. My testing result shows edn has a 5-10% performance improvement by linaro 4.5 with armv7_a option.
There are other technical solutions such as: * Building libgcc and glibc for the different variants and picking the best at link time * Building them and picking at dynamic link time using hwcaps or similar
These make sense for a generic binary toolchain such as the CodeSourcery one Andrew mentioned, and for generic distributions such as Ubuntu but not for a focused end user product.
Then my conclusion is that the best choice for cortex A9 with vfpv3 is 1. using linaro gcc 4.4/4.5 with ARMV7 optimization 2. using glibc compiled with vfpv3 supporting
A strange phenomenon i found was nbench would enter dead loop in ASSIGNMENT case. It could finish ASSIGNMENT case forever. nbench can be downloaded from http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz. I haven't time to figure out whether it is a linaro gcc bug. Then i just ignore this case by writing NBENCH.CONF like the following: CUSTOMRUN=T DONUMSORT=T DOLU=T DOSTRINGSORT=T DOBITFIELD=T DOEMF=T DOFOUR=T DOASSIGN=F ASSIGNMINSECONDS=1 DOHUFF=T DOIDEA=T
If you have time, may you help to check the reason?
-- Michael
Thanks Barry
On Tue, Mar 29, 2011 at 5:40 PM, Barry Song 21cnbao@gmail.com wrote:
2011/3/24 Michael Hope michael.hope@linaro.org:
Hi Barry. The short answer is 'it depends' :)
GCC is more than a compiler and includes other things such as a runtime library (libgcc) and hooks into the libc for features like thread local storage. These are built for the architecture and floating point unit options you pass to GCC's configure, so if you want one toolchain that runs everywhere then you need to configure it for the lowest common denominator (normally a ARMv5T in ARM mode with no FPU). A similar argument applies to GLIBC.
The next question is, does this matter for your application? What workload will your product run and will it be meaningfully affected by this lowest common denominator build? * If your application uses a lot of floating point, then the lack of FPU support in GLIBC matters
Completely right. I got a linaro 4.5 by:
sudo add-apt-repository ppa:linaro-maintainers/toolchain sudo apt-get update sudo apt-get install gcc-4.5-arm-linux-gnueabi
Then I did WHETSTONE benchmark on a low-frequency cortex A9 FPGA with vfpv3.
Result showed linaro by apt-get is using generic glibc in fact. its gave only 3.3 WHETSTONE MIPS. Then i compiled a glibc with vfpv3 support to replace the glibc by apt-get, the new toolchain gave 16.7 WHETSTONE MIPS, 400% improvement in WHETSTONE.
Whetstone is a floating point benchmark, so I'd expect this type of improvement.
* If your product has limited memory, then the smaller code size of Thumb-2 is worthwhile * If you need to squeeze out another 5 % in performance, then using ARMv7 instead of ARMv5 will help
Completely right. I did a edn benchmark from http://www.mrtc.mdh.se/projects/wcet/wcet_bench/edn/edn.c. EDN can show memory and fixed-point performance. My testing result shows edn has a 5-10% performance improvement by linaro 4.5 with armv7_a option.
Nice :) This matches what I've seen.
Then my conclusion is that the best choice for cortex A9 with vfpv3 is
- using linaro gcc 4.4/4.5 with ARMV7 optimization
- using glibc compiled with vfpv3 supporting
A strange phenomenon i found was nbench would enter dead loop in ASSIGNMENT case. It could finish ASSIGNMENT case forever. nbench can be downloaded from http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz. I haven't time to figure out whether it is a linaro gcc bug. Then i just ignore this case by writing NBENCH.CONF like the following: CUSTOMRUN=T DONUMSORT=T DOLU=T DOSTRINGSORT=T DOBITFIELD=T DOEMF=T DOFOUR=T DOASSIGN=F ASSIGNMINSECONDS=1 DOHUFF=T DOIDEA=T
If you have time, may you help to check the reason?
I couldn't reproduce this, sorry. I built nbench using gcc-linaro-4.5-2011.03-0 using both -O3 -mtune=cortex-a9 -mfpu=vfpv3-d16 and -O3 -mtune=cortex-a9 -mfpu=neon and in both cases ASSIGNMENT completes.
-- Michael
2011/3/30 Michael Hope michael.hope@linaro.org:
On Tue, Mar 29, 2011 at 5:40 PM, Barry Song 21cnbao@gmail.com wrote:
2011/3/24 Michael Hope michael.hope@linaro.org:
Hi Barry. The short answer is 'it depends' :)
GCC is more than a compiler and includes other things such as a runtime library (libgcc) and hooks into the libc for features like thread local storage. These are built for the architecture and floating point unit options you pass to GCC's configure, so if you want one toolchain that runs everywhere then you need to configure it for the lowest common denominator (normally a ARMv5T in ARM mode with no FPU). A similar argument applies to GLIBC.
The next question is, does this matter for your application? What workload will your product run and will it be meaningfully affected by this lowest common denominator build? * If your application uses a lot of floating point, then the lack of FPU support in GLIBC matters
Completely right. I got a linaro 4.5 by:
sudo add-apt-repository ppa:linaro-maintainers/toolchain sudo apt-get update sudo apt-get install gcc-4.5-arm-linux-gnueabi
Then I did WHETSTONE benchmark on a low-frequency cortex A9 FPGA with vfpv3.
Result showed linaro by apt-get is using generic glibc in fact. its gave only 3.3 WHETSTONE MIPS. Then i compiled a glibc with vfpv3 support to replace the glibc by apt-get, the new toolchain gave 16.7 WHETSTONE MIPS, 400% improvement in WHETSTONE.
Whetstone is a floating point benchmark, so I'd expect this type of improvement.
* If your product has limited memory, then the smaller code size of Thumb-2 is worthwhile * If you need to squeeze out another 5 % in performance, then using ARMv7 instead of ARMv5 will help
Completely right. I did a edn benchmark from http://www.mrtc.mdh.se/projects/wcet/wcet_bench/edn/edn.c. EDN can show memory and fixed-point performance. My testing result shows edn has a 5-10% performance improvement by linaro 4.5 with armv7_a option.
Nice :) This matches what I've seen.
Then my conclusion is that the best choice for cortex A9 with vfpv3 is
- using linaro gcc 4.4/4.5 with ARMV7 optimization
- using glibc compiled with vfpv3 supporting
A strange phenomenon i found was nbench would enter dead loop in ASSIGNMENT case. It could finish ASSIGNMENT case forever. nbench can be downloaded from http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz. I haven't time to figure out whether it is a linaro gcc bug. Then i just ignore this case by writing NBENCH.CONF like the following: CUSTOMRUN=T DONUMSORT=T DOLU=T DOSTRINGSORT=T DOBITFIELD=T DOEMF=T DOFOUR=T DOASSIGN=F ASSIGNMINSECONDS=1 DOHUFF=T DOIDEA=T
If you have time, may you help to check the reason?
I couldn't reproduce this, sorry. I built nbench using gcc-linaro-4.5-2011.03-0 using both -O3 -mtune=cortex-a9 -mfpu=vfpv3-d16 and -O3 -mtune=cortex-a9 -mfpu=neon and in both cases ASSIGNMENT completes.
Thanks. i will check whether it is our chip issue.
here one question: how much arm-linux-gnueabi-gcc depends on glibc version?
i run apt-get linaro 4.4, then got linaro 4.5 too. i found 4.5 was using glibc 2.12, but old 4.4 was using 2.11. apt-get 4.5 modified glibc from 2.11 to 2.12. But 4.4 could still use new glibc to compile and we haven't had any problem by now. I even recompiled a glibc 2.13 to replace current 2.12, but i didn't recompile gcc based on the glibc, the toolchain 4.4 and 4.5 can still work.
As i know, we compile arm-linux-gnueabi-gcc by following steps: 1. compile gcc 1, bootstrap in fact 2. compile glibc by gcc1 3. compile gcc2 based on glibc from step 2.
why can toolchain still work well by the steps? 1. keep arm-linux-gnueabi-gcc unchanged 2. replace glibc So i am not sure whether any hidden problem exist by replacing glibc simply.
one more question, my ubuntu 10.10 always said "/lib/libc.so.6: file not recognized: File format not recognized" if i enabled c++ language when compiling linaro gcc 4.4 and 4.5. Then i can't install libstdc++-v3 with errors like: /bin/sh: line 3: cd: arm-none-linux-gnueabi/libstdc++-v3: No such file or directory make[1]: *** [install-target-libstdc++-v3] Error 1
In fact, my version matches:
$ /lib/libc.so.6 GNU C Library (Ubuntu EGLIBC 2.12.1-0ubuntu10.2) stable release version 2.12.1, by Roland McGrath et al. Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.5. Compiled on a Linux 2.6.35 system on 2011-01-21. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: http://www.debian.org/Bugs/.
$ uname -a Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux
-- Michael
On Fri, Apr 1, 2011 at 3:09 PM, Barry Song 21cnbao@gmail.com wrote:
2011/3/30 Michael Hope michael.hope@linaro.org:
I couldn't reproduce this, sorry. I built nbench using gcc-linaro-4.5-2011.03-0 using both -O3 -mtune=cortex-a9 -mfpu=vfpv3-d16 and -O3 -mtune=cortex-a9 -mfpu=neon and in both cases ASSIGNMENT completes.
Thanks. i will check whether it is our chip issue.
here one question: how much arm-linux-gnueabi-gcc depends on glibc version?
i run apt-get linaro 4.4, then got linaro 4.5 too. i found 4.5 was using glibc 2.12, but old 4.4 was using 2.11. apt-get 4.5 modified glibc from 2.11 to 2.12. But 4.4 could still use new glibc to compile and we haven't had any problem by now. I even recompiled a glibc 2.13 to replace current 2.12, but i didn't recompile gcc based on the glibc, the toolchain 4.4 and 4.5 can still work.
As i know, we compile arm-linux-gnueabi-gcc by following steps:
- compile gcc 1, bootstrap in fact
- compile glibc by gcc1
- compile gcc2 based on glibc from step 2.
why can toolchain still work well by the steps?
- keep arm-linux-gnueabi-gcc unchanged
- replace glibc
So i am not sure whether any hidden problem exist by replacing glibc simply.
You should be OK as glibc supports versioned symbols. Providing your glibc is newer, any functions that have changed in functionality should include a versioned, backwards compatible version.
Ask youself why you are doing this though. If it's just to save time, then I wouldn't recommend it. It adds another variable to your product which may bite you later on.
one more question, my ubuntu 10.10 always said "/lib/libc.so.6: file not recognized: File format not recognized" if i enabled c++ language when compiling linaro gcc 4.4 and 4.5. Then i can't install libstdc++-v3 with errors like: /bin/sh: line 3: cd: arm-none-linux-gnueabi/libstdc++-v3: No such file or directory make[1]: *** [install-target-libstdc++-v3] Error 1
This is probably due to a configuration problem. The ARM build is picking up the x86 libc6 from the host machine and rightly complaining that it's incompatible. Try adding '--enable-poison-system-directories' to your configure options. That should help track it down.
-- Michael
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
Barry Song -
Imre Kaloz -
Michael Hope