On Fri, Mar 25, 2011 at 2:59 AM, Barry Song <21cn...@gmail.com> wrote: > 2011/3/24 Andrew Stubbs <andrew.stu...@linaro.org> >> >> On 24/03/11 11:05, Imre Kaloz wrote: >>> >>> On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs >>> <andrew.stu...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
