Re: [coreboot] r3085 build service

[Marc Karasek]

Sorry about that...

/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:[e-mail]
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 :
> 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 [e-mail]:
> > Quoting Marc Karasek :
> > > 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_c...
> > >
> > > 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