<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
All,<br>
<br>
I do not know if this is the same problem I faced with the .id
section.  But it looks really familiar. <br>
<br>
I had tracked this down to a bug in binutils that was already reported
and fixed in the cvs.  Someone one the list haad found a newer binutils
(2.18) and had installed the rpm from it.  he then tried to compile and
it worked fine.   I will look for the link to the mailing list I found
that described the problem.  <br>
<br>
Whomever tested this had the link tot he 2.18 binutils rpm release. <br>
<br>
Marc<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>