I'm writing this as a bug for the GMP community and CCing coreboot, although, with the proper direction I can imagine this all ending in a change to the configure flags in the coreboot xgcc build.
The coreboot project contains a build script for generating a cross toolchain (xgcc). The versions were recently bumped to: GMP_VERSION=5.0.5 MPFR_VERSION=3.1.0 MPC_VERSION=0.9 LIBELF_VERSION=0.8.13 GCC_VERSION=4.6.3 GCC_AUTOCONF_VERSION=2.64 BINUTILS_VERSION=2.22
For the purposes of this bug, the important change was the move from GMP 5.0.2 to GMP 5.0.5. The issue is that an xgcc toolchain built on one host cannot consistently be moved to a similar operating system on a different host with a different underlying architecture. This was seen with both 32bit and 64bit OS installs under the following configurations:
64bit Build Host Ubuntu 11.04 \n \l Linux ubuntubuilder03 2.6.38-14-server #58-Ubuntu SMP Tue Mar 27 20:21:58 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux vendor_id : AuthenticAMD model name : AMD Athlon(tm) II X4 605e Processor
64bit Execution Host Ubuntu 10.04.3 LTS \n \l Linux beast 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
32bit Build Host Ubuntu 11.04 \n \l Linux ubuntubuilder04 2.6.38-14-generic-pae #58-Ubuntu SMP Tue Mar 27 19:06:30 UTC 2012 i686 athlon i386 GNU/Linux vendor_id : AuthenticAMD model name : Embedded AMD Opteron(tm) Processor 41KX HE NOTE: The architecture is 64bit, but the operating system is 32bit
32bit Execution Host Ubuntu 11.10 \n \l Linux test2 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 17:34:21 UTC 2012 i686 i686 i386 GNU/Linux vendor_id : GenuineIntel model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
The following issue symptom does not seem to be limited to Linux operating systems. Cygwin builds using Windows XP VMs and native Windows installs also exhibit the problem. On Linux systems, in the coreboot build on the execution host using a tar'd and copied binary toolchain from the build host resulted in messages like:
libpci/libpci.c:221:1: internal compiler error: Illegal instruction make[1]: Entering directory `/home/tester/sage_edk/release_workspace/coreboot/payloads/libpayload' CC libpci/libpci.libpci.o Please submit a full bug report, with preprocessed source if appropriate. Seehttp://gcc.gnu.org/bugs.html for instructions. make[1]: Leaving directory `/home/tester/sage_edk/release_workspace/coreboot/payloads/libpayload' make[1]: *** [build/libpci/libpci.libpci.o] Error 1 make: *** [libpayload] Error 2
or
./src/cpu/amd/agesa/cache_as_ram.inc: Assembler messages: ./src/cpu/amd/agesa/cache_as_ram.inc:67: Error: unbalanced parenthesis in operand 1.
or
romstage.c: Assembler messages: romstage.c:476: Error: value of 4294967296 too large for field of 4 bytes at 4448 romstage.c:477: Error: value of 4294967296 too large for field of 4 bytes at 4460 <snip>
On Cygwin systems, the build resulted in messages like:
cc1: out of memory allocating 67174399 bytes after a total of 336396288 bytes Makefile:238: recipe for target `build/console/vtxprintf.romstage.o' failed
I performed a bisect of the GMP mercurial repository and identified an offending changeset: http://gmplib.org:8000/gmp-5.0/rev/2b7b8ada8a20
By this, I mean, that the xgcc toolchain, when built with any change prior to this GMP version, was able to compile coreboot when moved between build and execution host. I constructed a patch for GMP 5.0.5 reversing this change (attached). Similarly, with this patch, the xgcc toolchain using GMP 5.0.5 is portable.
Are the tuning changes made in this change optimal? What are the GMP recommendations for constructing a toolchain that is portable between similar hosts?
Thanks, Ray
Raymond Danks Sage Electronic Engineering, LLC