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. > 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. Thanks for analyzing the problem. I hope you find the culprit. Regards, Carl-Daniel -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
