2.6.26-gitX: insane number of section headers

2.6.26-gitX: insane number of section headers

[Manuel Lauss]

Hello,

Todays 2.6.26-git kernel produces an insane amout of section headers in the
vmlinux file, one for every function. Is that intentional, or a toolchain
problem on my side (binutils-2.18, gcc-4.2.4)?

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x801045d0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          29726396 (bytes into file)
  Flags:                             0x50001001, noreorder, o32, mips32
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         9282
  Section header string table index: 9279

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk
Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0
0  0
  [ 1] .text             PROGBITS        80100000 002000 009bd0 00  AX  0
0 32
  [ 2] .text.run_init_pr PROGBITS        80109bd0 00bbd0 000018 00  AX  0
0  4
  [ 3] .text.init_post   PROGBITS        80109be8 00bbe8 0000f0 00  AX  0
0  4
  [ 4] .text.name_to_dev PROGBITS        80109cd8 00bcd8 0002dc 00  AX  0
0  4
  [ 5] .text.prom_getcmd PROGBITS        80109fb4 00bfb4 00000c 00  AX  0
0  4
  [ 6] .text.prom_init_c PROGBITS        80109fc0 00bfc0 0000c4 00  AX  0
0  4
  [ 7] .text.prom_getenv PROGBITS        8010a084 00c084 000110 00  AX  0
0  4
  [ 8] .text.prom_get_et PROGBITS        8010a194 00c194 000160 00  AX  0
0  4
  [ 9] .text.local_enabl PROGBITS        8010a2f4 00c2f4 000048 00  AX  0
0  4
  [10] .text.local_disab PROGBITS        8010a33c 00c33c 000048 00  AX  0
0  4
  [11] .text.plat_irq_di PROGBITS        8010a384 00c384 000220 00  AX  0
0  4
  [12] .text.restore_au1 PROGBITS        8010a5a4 00c5a4 00021c 00  AX  0
0  4
  [13] .text.mask_and_ac PROGBITS        8010a7c0 00c7c0 000048 00  AX  0
0  4
  [14] .text.mask_and_ac PROGBITS        8010a808 00c808 000048 00  AX  0
0  4
  [15] .text.mask_and_ac PROGBITS        8010a850 00c850 000050 00  AX  0
0  4
  [16] .text.save_au1xxx PROGBITS        8010a8a0 00c8a0 000154 00  AX  0


Thanks!
	Manuel Lauss

Re: 2.6.26-gitX: insane number of section headers

[Manuel Lauss]

On Wed, Jul 16, 2008 at 09:52:46AM +0200, Manuel Lauss wrote:
> Hello,
> 
> Todays 2.6.26-git kernel produces an insane amout of section headers in the
> vmlinux file, one for every function. Is that intentional, or a toolchain
> problem on my side (binutils-2.18, gcc-4.2.4)?

I see Ralf added -ffunction-sections with commit
372a775f50347f5c1dd87752b16e5c05ea965790.

Sorry for the noise.

	Manuel Lauss

Re: 2.6.26-gitX: insane number of section headers

[Ralf Baechle]

On Wed, Jul 16, 2008 at 10:15:32AM +0200, Manuel Lauss wrote:

> On Wed, Jul 16, 2008 at 09:52:46AM +0200, Manuel Lauss wrote:
> > Hello,
> > 
> > Todays 2.6.26-git kernel produces an insane amout of section headers in the
> > vmlinux file, one for every function. Is that intentional, or a toolchain
> > problem on my side (binutils-2.18, gcc-4.2.4)?
> 
> I see Ralf added -ffunction-sections with commit
> 372a775f50347f5c1dd87752b16e5c05ea965790.

I consider that an experimental commit.  It's meant to solve the problems
we're having on a few very large compilation units with the limited length
of branches.  But if the cure turns out to be worse than the illness I'm
ready to pull it again.

A more proper patchset should modify the linker scripts to avoid the
excessive large number of sections you've noticed.  Somebody else is
currently working on a patchset to allow the --gc-sections ld option so
I decieded to take the path of least resistance for now.

  Ralf

Re: 2.6.26-gitX: insane number of section headers

[Manuel Lauss]

On Wed, Jul 16, 2008 at 11:59:27AM +0100, Ralf Baechle wrote:
> On Wed, Jul 16, 2008 at 10:15:32AM +0200, Manuel Lauss wrote:
> 
> > On Wed, Jul 16, 2008 at 09:52:46AM +0200, Manuel Lauss wrote:
> > > Hello,
> > > 
> > > Todays 2.6.26-git kernel produces an insane amout of section headers in the
> > > vmlinux file, one for every function. Is that intentional, or a toolchain
> > > problem on my side (binutils-2.18, gcc-4.2.4)?
> > 
> > I see Ralf added -ffunction-sections with commit
> > 372a775f50347f5c1dd87752b16e5c05ea965790.
> 
> I consider that an experimental commit.  It's meant to solve the problems
> we're having on a few very large compilation units with the limited length
> of branches.  But if the cure turns out to be worse than the illness I'm
> ready to pull it again.

If it fixes bugs for people, then by all means leave it in.  I was just
curious because my self-written bootloader complained about it.

Thanks for the explanation.

Manuel Lauss

Re: 2.6.26-gitX: insane number of section headers

[Ralf Baechle]

On Wed, Jul 16, 2008 at 01:03:57PM +0200, Manuel Lauss wrote:

> > I consider that an experimental commit.  It's meant to solve the problems
> > we're having on a few very large compilation units with the limited length
> > of branches.  But if the cure turns out to be worse than the illness I'm
> > ready to pull it again.
> 
> If it fixes bugs for people, then by all means leave it in.  I was just
> curious because my self-written bootloader complained about it.

I wonder why your bootloader cares about sections.  Normally a bootloader
only ever should think about segments and the number of segments the
sections are getting mapped to should be unchanged by my patch.

> Thanks for the explanation.

Immer doch :-)

  Ralf

Re: 2.6.26-gitX: insane number of section headers

[Manuel Lauss]

On Wed, Jul 16, 2008 at 12:08:48PM +0100, Ralf Baechle wrote:
> On Wed, Jul 16, 2008 at 01:03:57PM +0200, Manuel Lauss wrote:
> 
> > > I consider that an experimental commit.  It's meant to solve the problems
> > > we're having on a few very large compilation units with the limited length
> > > of branches.  But if the cure turns out to be worse than the illness I'm
> > > ready to pull it again.
> > 
> > If it fixes bugs for people, then by all means leave it in.  I was just
> > curious because my self-written bootloader complained about it.
> 
> I wonder why your bootloader cares about sections.  Normally a bootloader
> only ever should think about segments and the number of segments the
> sections are getting mapped to should be unchanged by my patch.

It doesn't -- I just thought that if the number ever gets bigger than what
used to be the norm in alchemy-land then a) flash is erased, or b) something
broke.

 
> > Thanks for the explanation.
> 
> Immer doch :-)

Vielen Dank!

Manuel Lauss

Re: 2.6.26-gitX: insane number of section headers

[Atsushi Nemoto]

On Wed, 16 Jul 2008 11:59:27 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> > I see Ralf added -ffunction-sections with commit
> > 372a775f50347f5c1dd87752b16e5c05ea965790.
> 
> I consider that an experimental commit.  It's meant to solve the problems
> we're having on a few very large compilation units with the limited length
> of branches.  But if the cure turns out to be worse than the illness I'm
> ready to pull it again.
> 
> A more proper patchset should modify the linker scripts to avoid the
> excessive large number of sections you've noticed.  Somebody else is
> currently working on a patchset to allow the --gc-sections ld option so
> I decieded to take the path of least resistance for now.

With this commit, the _etext symbol appeared in middle of text area.
I got _etext=0x80108438 and _text=0x80100000, but my kernel is much
bigger, of course.

Reverting the commit solved the problem.  I'm using gcc 4.3.1 and
binutils 2.18.

---
Atsushi Nemoto