[coreboot] r3085 build service

[Stefan Reinauer]

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.


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


Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080128/65e8bd10/attachment.sig>