[coreboot] r3085 build service

[Carl-Daniel Hailfinger]

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