Sorry about that... /********************* Marc Karasek MTS Sun Microsystems mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]: > >> Quoting Marc Karasek <[EMAIL PROTECTED]>: >> >>> 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 >> >> -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
