RE: [HOW] binutils-2.17 breaks the 2.6.26 kernel

2008-07-21 Thread Rune Torgersen 
 From: Segher Boessenkool
  Previous threads have mentioned that binutil-2.17 is broken for
  building powerpc kernels. It is fixed in binutils-2.18.
 
 I have a working (tested! thanks Milton) workaround for the current
 problem, will send it later today.  This problem funnily is hidden
 by the presence of build-id :-)

Did you ever send this patch? I'd like to try it as I cannot compile a
arch/powerpc 2.6.265 kernel right now.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [HOW] binutils-2.17 breaks the 2.6.26 kernel

2008-07-17 Thread Segher Boessenkool 

Previous threads have mentioned that binutil-2.17 is broken for
building powerpc kernels. It is fixed in binutils-2.18.


Yes.


I have encountered this and upgrading to 2.18 fixed my build. The
symptom is large kernel sizes and a long time in gzip. In my case it
was gziping a 2GB file.


Are you using a binary (non-ELF) image file?  This sounds like a
different problem, caused by the kernel linker script not handling
the build-id section correctly -- it places it at 0, and the rest
of the kernel at 3GB, you can imagine the rest.  I've seen this
on various embedded targets, but not on PowerPC iirc -- maybe I
don't build any affected defconfig, what's yours?


I have a working (tested! thanks Milton) workaround for the current
problem, will send it later today.  This problem funnily is hidden
by the presence of build-id :-)


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [HOW] binutils-2.17 breaks the 2.6.26 kernel

2008-07-16 Thread Segher Boessenkool 

. = ALIGN(0x1000)   /* this align directive aparently gets lost
   when stripping the file */

.rodata: AT (.rodata - LOAD_OFFSET): {
  ...
}

the effects of that align were dropped during strip, shifting all
following sections up in memory and the resulting failure.


The ELF headers show the .rodata section to have 256 byte alignment
only, but after the bad strip it isn't even aligned to that
anymore (file offset).  Curious.

I still can't reproduce this, but getting the bad binary now (it's
huge, heh).  We'll see.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [HOW] binutils-2.17 breaks the 2.6.26 kernel

2008-07-16 Thread Jon Smirl 
On 7/16/08, Milton Miller [EMAIL PROTECTED] wrote:
 Hi.

Previous threads have mentioned that binutil-2.17 is broken for
building powerpc kernels. It is fixed in binutils-2.18.

I have encountered this and upgrading to 2.18 fixed my build. The
symptom is large kernel sizes and a long time in gzip. In my case it
was gziping a 2GB file.


  I've been working with Debian bintuils 2.17-3 (which identifies
  itself as 2.17) on my build box for some time.

  When testing all-yes-config, I was getting warnings, but the
  vmlinux was booting via kexec.

  Since I was replicating the warnings from BFD about section lmas
  overlapping in vmlinux.strip.$$, I was encouraged to actually try
  booting the resulting stripped kernel.  After a false start (getting
  the old binary) I ended up replicating the fail-to-boot some people
  have reported on linuxppc-dev.

  Digging into the failure, we were trying to copy *way* too much data
  in copy_and_flush from after_prom.   I found the value loaded from
  _klimit was something like 0x2fea_0040, not quite _end that
  it was initialized.

  I tracked this down to the .rodata and all sections following loosing
  the inter-section alignment.


  /DISCARD/ {
   
  }
  text: AT( .text - LOAD_OFFSET): {
   
  }

  . = ALIGN(0x1000)   /* this align directive aparently gets lost
when stripping the file */

  .rodata: AT (.rodata - LOAD_OFFSET): {
   ...
  }

  the effects of that align were dropped during strip, shifting all
  following sections up in memory and the resulting failure.

  I don't know if the fault is ld or strip.

  The behavior came between 2.6.24 and -next-20080710, but others
  have suggested their kernels don't boot in the 2.6.25 to 2.6.26
  transition, and a likely candidate is the addition of AT(x) to
  set the lma, although we also switched form TEXT_TEXT macro in
  include/asm-generic.h to a hand-rolled .text section.

  Can we come up with a workaround?

  thanks,
  milton

  ___
  Linuxppc-dev mailing list
  Linuxppc-dev@ozlabs.org
  https://ozlabs.org/mailman/listinfo/linuxppc-dev



-- 
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [HOW] binutils-2.17 breaks the 2.6.26 kernel

2008-07-16 Thread Gabriel Paubert 
On Wed, Jul 16, 2008 at 08:38:14PM -0400, Jon Smirl wrote:
 On 7/16/08, Milton Miller [EMAIL PROTECTED] wrote:
  Hi.
 
 Previous threads have mentioned that binutil-2.17 is broken for
 building powerpc kernels. It is fixed in binutils-2.18.
 
 I have encountered this and upgrading to 2.18 fixed my build. The
 symptom is large kernel sizes and a long time in gzip. In my case it
 was gziping a 2GB file.

Only? Mine was over 3GB :-)

I've not yet had time to update the binutils (the machine has
a standard Debian Etch and I have trouble when adding Lenny
sources).

I also bisected it for fun and got 366234f6 as the culprit.

Gabriel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev