On 28.01.2008 22:32, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: >> On 28.01.2008 22:12, Jordan Crouse wrote: >> >>> On 28/01/08 21:38 +0100, Carl-Daniel Hailfinger wrote: >>> >>>> On 28.01.2008 21:12, coreboot information wrote: >>>> >>>>> revision 3085 >>>>> >>>>> Build Log: >>>>> Compilation of amd:serengeti_cheetah has been fixed >>>>> Compilation of amd:serengeti_cheetah_fam10 is still broken >>>>> See the error log at >>>>> http://qa.coreboot.org/log_buildbrd.php?revision=3085&device=serengeti_cheetah_fam10&vendor=amd >>>>> >>>>> >>>> And we need another 2461 bytes increase due to the new compiler. >>>> Just in >>>> case anyone wonders which compiler causes continuous size increases: >>>> >>>> gcc version 4.3.0 20080117 (experimental) [trunk revision 131592] >>>> (SUSE Linux) >>>> >>> Nak. This is a more serious problem: >>> >>> My system is: >>> gcc version 4.1.3 20070929 (prerelease) (Ubuntu4.1.2-16ubuntu2) >>> >>> My sections are as follows: >>> .ram start 0xfffc0000 size 0x10098 >>> .rom start 0xfffd0098 size 0xfac8 >>> .id start 0xfffefd2 >>> On the log from abuild, we can interpolate the results. .ram start is >>> hardcoded, and .rom starts immediately after .ram. So, based on >>> this line: >>> >>> Section .id [00000000ffffefd2 -> 00000000ffffefef] overlaps section >>> .rom >>> [00000000fffedd7c -> 00000000fffff96f] >>> >>> We see that the .ram is (0xfffedd7c - 0xfffd0098) 122084 bytes >>> larger on >>> the abuild machine then it is on my machine. That certainly isn't >>> because >>> of little changes in the compiler. And .rom too has an increase, >>> (0xfffff96f - 0xfffedd7c = 72691), which is 8491 bytes larger then >>> my box. >>> >> >> That is way outside the expected variation. >> >> > If you tell me how I can help, I'll be glad to do it.
Testing with other gcc versions and creating a size table like the one at http://coreboot.org/~jcrouse/ubuntu_4_1_fam10_sizes would certainly help us see where the whole size problem is most apparent. >>> Something is amiss here, and I need to put my head down with Stefan >>> and figure it out. But in the meantime, hiding the problem isn't >>> going to help >>> anybody. >>> >> >> Downgrading gcc on the official build machine would probably shed some >> light on the situation. >> > How so? It will just remove the issue until the new gcc becomes widely > usable. It will at least tell us if this is purely gcc related or gcc+binutils related. http://gcc.gnu.org/ml/gcc/2008-01/msg00507.html says that the regression count in the gcc 4.3.0 branch has gone down a lot in the last week. The gcc snapshot you're using is over a week old. Maybe a current snapshot will cause less breakage. By the way, http://gcc.gnu.org/gcc-4.3/porting_to.html and http://gcc.gnu.org/gcc-4.3/changes.html say a few interesting things which could/will affect our code: - GCC no longer places the |cld| instruction before string operations. Both i386 and x86-64 ABI documents mandate the direction flag to be clear at the entry of a function. It is now invalid to set the flag in |asm| statement without reseting it afterward. - |Fastcall| for i386 has been changed not to pass aggregate arguments in registers, following Microsoft compilers. - The |constructor| and |destructor| function attributes now accept optional priority arguments which control the order in which the constructor and destructor functions are run. - Semantic change of extern inline: When compiling with |-std=c99| or |-std=gnu99|, the |extern inline| keywords changes meaning. GCC 4.3 conforms to the ISO C99 specification, where |extern inline| is very different thing than the GNU |extern inline| extension. Once the cause for the size increase is known, we have to file a bug with the gcc developers. Regards, Carl-Daniel -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
