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_c...
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