[coreboot] r3085 build service

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Mon Jan 28 23:33:42 CET 2008


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




More information about the coreboot mailing list