<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Here is my message about the .id bug in binutils<br>
<br>
/***************************************************<br>
<br>
After some more investigating I think I have found the core problem
with the id.lds file. <br>
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.
<br>
<br>
My question is do we leave the patch in place or just make a note
somewhere that if you see this problem :
<br>
1) Upgrade binutils (if possible)
<br>
or
<br>
2) Make changes to id.lds
<br>
<br>
<br>
<a class="moz-txt-link-freetext"
href="http://www.nabble.com/binutils-2.18-and-U-Boot-td14266866.html">http://www.nabble.com/binutils-2.18-and-U-Boot-td14266866.html</a>
<br>
<br>
/*********************************************************<br>
<br>
<br>
Here is the message from the person who tested the 2.18 binutils :<br>
<br>
/**************************************************<br>
<div class="moz-text-flowed"
style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">Quoting
<a class="moz-txt-link-abbreviated"
href="mailto:joe@smittys.pointclark.net:">joe@smittys.pointclark.net:</a>
<br>
<br>
<blockquote type="cite">Quoting Marc Karasek <a
class="moz-txt-link-rfc2396E" href="mailto:Marc.Karasek@Sun.COM"><Marc.Karasek@Sun.COM></a>:
<br>
<br>
<blockquote type="cite">It was not specifically x86_64 related. It
was however fedora 8
<br>
related. I think in my research that it has to do with the version of
<br>
binutils. I had sent out a mail to the reflector with a link to
<br>
another discussion group regarding binutils and a bug that looked like
<br>
it was this. According to the thread, a patch had been submitted to
<br>
the binutils tree to fix this issue. The version of binutils I have
<br>
that shows this problem is 2.17.50.0.18-1 2007073. I am looking to
<br>
upgrade to 2.18 as soon as it is avail (rpm) to see if this is fixed.
<br>
<br>
</blockquote>
I found someone that built binutils-2.18.50.0.3-1 rpms here:
<br>
<br>
<a class="moz-txt-link-freetext"
href="http://koji.fedoraproject.org/koji/buildinfo?buildID=27856">http://koji.fedoraproject.org/koji/buildinfo?buildID=27856</a>
<br>
<br>
I will try it out and report back
<br>
<br>
</blockquote>
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.
<br>
<br>
Thanks - Joe
<br>
<br>
/*******************************************<br>
</div>
<br>
<br>
<br>
Jordan Crouse wrote:
<blockquote cite="mid:20080128211212.GB9275@cosmic.amd.com" type="cite">
<pre wrap="">On 28/01/08 21:38 +0100, Carl-Daniel Hailfinger wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 28.01.2008 21:12, coreboot information wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-freetext" href="http://qa.coreboot.org/log_buildbrd.php?revision=3085&device=serengeti_cheetah_fam10&vendor=amd">http://qa.coreboot.org/log_buildbrd.php?revision=3085&device=serengeti_cheetah_fam10&vendor=amd</a>
</pre>
</blockquote>
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</body>
</html>