Dear coreboot readers!
This is the automated build check service of coreboot.
The developer "jcrouse" checked in revision 3085 to the coreboot source repository and caused the following changes:
Change Log: [V2]: Add CFLAGS to targets to suck in any passed in flags
Signed-off-by: Jordan Crouse jordan.crouse@amd.com Acked-by: Ronald G. Minnich rminnich@gmail.com
Build Log: Compilation of a-trend:atc-6220 has been fixed Compilation of abit:be6-ii_v2_0 has been fixed Compilation of advantech:pcm-5820 has been fixed Compilation of agami:aruma has been fixed Compilation of amd:db800 has been fixed Compilation of amd:norwich has been fixed Compilation of amd:rumba has been fixed 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... Compilation of arima:hdama has been fixed Compilation of artecgroup:dbe61 has been fixed Compilation of asi:mb_5blmp has been fixed Compilation of asus:a8n_e has been fixed Compilation of asus:a8v-e_se has been fixed Compilation of asus:mew-am has been fixed Compilation of asus:mew-vm has been fixed Compilation of asus:p2b has been fixed Compilation of asus:p2b-f has been fixed Compilation of asus:p3b-f has been fixed Compilation of axus:tc320 has been fixed Compilation of azza:pt-6ibd has been fixed Compilation of bcom:winnet100 has been fixed Compilation of biostar:m6tba has been fixed Compilation of broadcom:blast has been fixed Compilation of compaq:deskpro_en_sff_p600 has been fixed Compilation of dell:s1850 has been fixed Compilation of digitallogic:adl855pc has been fixed Compilation of digitallogic:msm586seg has been fixed Compilation of digitallogic:msm800sev has been fixed Compilation of eaglelion:5bcm has been fixed Compilation of emulation:qemu-i386 has been fixed Compilation of gigabyte:ga-6bxc has been fixed Compilation of gigabyte:ga_2761gxdk has been fixed Compilation of gigabyte:m57sli has been fixed Compilation of ibm:e325 has been fixed Compilation of ibm:e326 has been fixed Compilation of iei:juki-511p has been fixed Compilation of iei:nova4899r has been fixed Compilation of intel:jarrell has been fixed Compilation of intel:xe7501devkit has been fixed Compilation of iwill:dk8_htx has been fixed Compilation of iwill:dk8s2 has been fixed Compilation of iwill:dk8x has been fixed Compilation of lippert:frontrunner has been fixed Compilation of msi:ms6178 has been fixed Compilation of msi:ms7260 has been fixed Compilation of msi:ms9185 has been fixed Compilation of msi:ms9282 has been fixed Compilation of newisys:khepri has been fixed Compilation of nvidia:l1_2pvv has been fixed Compilation of olpc:btest has been fixed Compilation of olpc:rev_a has been fixed Compilation of pcengines:alix1c has been fixed Compilation of sunw:ultra40 has been fixed Compilation of supermicro:h8dmr has been fixed Compilation of supermicro:x6dai_g has been fixed Compilation of supermicro:x6dhe_g has been fixed Compilation of supermicro:x6dhe_g2 has been fixed Compilation of supermicro:x6dhr_ig has been fixed Compilation of supermicro:x6dhr_ig2 has been fixed Compilation of technologic:ts5300 has been fixed Compilation of tyan:s1846 has been fixed Compilation of tyan:s2735 has been fixed Compilation of tyan:s2850 has been fixed Compilation of tyan:s2875 has been fixed Compilation of tyan:s2880 has been fixed Compilation of tyan:s2881 has been fixed Compilation of tyan:s2882 has been fixed Compilation of tyan:s2885 has been fixed Compilation of tyan:s2891 has been fixed Compilation of tyan:s2892 has been fixed Compilation of tyan:s2895 has been fixed Compilation of tyan:s2912 has been fixed Compilation of tyan:s4880 has been fixed Compilation of tyan:s4882 has been fixed Compilation of via:epia has been fixed Compilation of via:epia-m has been fixed
If something broke during this checkin please be a pain in jcrouse's neck until the issue is fixed.
If this issue is not fixed within 24h the revision should be backed out.
Best regards, coreboot automatic build system
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)
Regards, Carl-Daniel
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: LinuxBIOSv2-myCAR/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb =================================================================== --- LinuxBIOSv2-myCAR/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb (Revision 3085) +++ LinuxBIOSv2-myCAR/targets/amd/serengeti_cheetah_fam10/Config-abuild.lb (Arbeitskopie) @@ -13,7 +13,7 @@
romimage "fallback" option USE_FALLBACK_IMAGE=1 - option ROM_IMAGE_SIZE=0x21000 + option ROM_IMAGE_SIZE=0x22000 option COREBOOT_EXTRA_VERSION=".0-fallback" payload __PAYLOAD__ end
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
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_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.
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
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_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.
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
On 28.01.2008 22:32, Stefan Reinauer wrote:
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_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.
That is way outside the expected variation.
If you tell me how I can help, I'll be glad to do it.
Testing with other gcc versions and creating a size table like the one at http://coreboot.org/~jcrouse/ubuntu_4_1_fam10_sizes would certainly help us see where the whole size problem is most apparent.
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.
It will at least tell us if this is purely gcc related or gcc+binutils related.
http://gcc.gnu.org/ml/gcc/2008-01/msg00507.html says that the regression count in the gcc 4.3.0 branch has gone down a lot in the last week. The gcc snapshot you're using is over a week old. Maybe a current snapshot will cause less breakage.
By the way, http://gcc.gnu.org/gcc-4.3/porting_to.html and http://gcc.gnu.org/gcc-4.3/changes.html say a few interesting things which could/will affect our code: - GCC no longer places the |cld| instruction before string operations. Both i386 and x86-64 ABI documents mandate the direction flag to be clear at the entry of a function. It is now invalid to set the flag in |asm| statement without reseting it afterward. - |Fastcall| for i386 has been changed not to pass aggregate arguments in registers, following Microsoft compilers. - The |constructor| and |destructor| function attributes now accept optional priority arguments which control the order in which the constructor and destructor functions are run. - Semantic change of extern inline: When compiling with |-std=c99| or |-std=gnu99|, the |extern inline| keywords changes meaning. GCC 4.3 conforms to the ISO C99 specification, where |extern inline| is very different thing than the GNU |extern inline| extension.
Once the cause for the size increase is known, we have to file a bug with the gcc developers.
Regards, Carl-Daniel
On 28/01/08 23:33 +0100, Carl-Daniel Hailfinger wrote:
Testing with other gcc versions and creating a size table like the one at http://coreboot.org/~jcrouse/ubuntu_4_1_fam10_sizes would certainly help us see where the whole size problem is most apparent.
Attached is the comparison of the sizes between 4.1 and 4.3. Most of the .o files are _smaller_ which is to be expected with a better compiler, but unexpected due to our results. But there is one uh-oh - crt0.o is 8k larger, which probably accounts for much of our missing space, but certainly not all of it.
We now have two missions - figure out whats up with crt0.o and figure out the next possible culprit (binutils, probably).
(also posted at: http://coreboot.org/~jcrouse/comparison_41_to_43)
Jordan
On 28/01/08 14:12 -0700, Jordan Crouse wrote:
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.
In that spirit, here are the sizes of the object files in my build for comparision.
http://coreboot.org/~jcrouse/ubuntu_4_1_fam10_sizes
Jordan
Sorry about that...
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@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 :
- 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@smittys.pointclark.net:
Quoting Marc Karasek Marc.Karasek@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_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
-
Carl-Daniel Hailfinger -
coreboot information -
Jordan Crouse -
Marc Karasek -
Stefan Reinauer