[coreboot] r3085 build service
Marc Karasek
Marc.Karasek at Sun.COM
Tue Jan 29 14:22:50 CET 2008
Sorry about that...
/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:marc.karasek at sun.com
ph:770.360.6415
*********************/
Marc Karasek wrote:
>
> Here is my message about the .id bug in binutils
>
> /***************************************************
>
> After some more investigating I think I have found the core problem
> with the id.lds file.
> I think this is a bug in binutils. if you look at the link below you
> will see an explanation. I have checked and I am using 2.17.50 on my
> system. this could explain the problem I am seeing with linking. It
> seems a check within ld is not working properly for sections that are
> at the top of an image/memory. (base+size = 0). Looks like a fix has
> been put into binutils already.
>
> My question is do we leave the patch in place or just make a note
> somewhere that if you see this problem :
> 1) Upgrade binutils (if possible)
> or
> 2) Make changes to id.lds
>
>
> http://www.nabble.com/binutils-2.18-and-U-Boot-td14266866.html
>
> /*********************************************************
>
>
> Here is the message from the person who tested the 2.18 binutils :
>
> /**************************************************
> Quoting joe at smittys.pointclark.net:
>
>> Quoting Marc Karasek <Marc.Karasek at Sun.COM>:
>>
>>> It was not specifically x86_64 related. It was however fedora 8
>>> related. I think in my research that it has to do with the version of
>>> binutils. I had sent out a mail to the reflector with a link to
>>> another discussion group regarding binutils and a bug that looked like
>>> it was this. According to the thread, a patch had been submitted to
>>> the binutils tree to fix this issue. The version of binutils I have
>>> that shows this problem is 2.17.50.0.18-1 2007073. I am looking to
>>> upgrade to 2.18 as soon as it is avail (rpm) to see if this is fixed.
>>>
>> I found someone that built binutils-2.18.50.0.3-1 rpms here:
>>
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=27856
>>
>> I will try it out and report back
>>
> SWEET:-) I rpm -Uvh 'd the three packages from the above link
> (binutils, binutils-devel, binutils-debuginfo) and everything is
> working great now, coreboot builds with no problems. Back in business
> again.
>
> Thanks - Joe
>
> /*******************************************
>
>
>
> 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.
>>
>> 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.
>>
>> Jordan
>>
>>
More information about the coreboot
mailing list