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