[HOW] binutils-2.17 breaks the 2.6.26 kernel

[HOW] binutils-2.17 breaks the 2.6.26 kernel

[Milton Miller]

Hi.

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 0x00002fea_00400000, 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

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

[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

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

[Jon Smirl]

On 7/16/08, Milton Miller <miltonm@bga.com> 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 0x00002fea_00400000, 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
jonsmirl@gmail.com

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

[Gabriel Paubert]

On Wed, Jul 16, 2008 at 08:38:14PM -0400, Jon Smirl wrote:
> On 7/16/08, Milton Miller <miltonm@bga.com> 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

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

[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

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

[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.
>=20
> 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.