On Thu, 3 Aug 2000 11:58:36 +0200 (METDST),
Gabriel Paubert [off-list ref] wrote:
What I hate in all this is that the combination of 2 bugs (no
ksymtab/kstrtab in vmlinux.lds and no definition of the start and stop
symbols) ends up in something working through behind the scenes black
magic. Perhaps names should be chosen such that they will never clash with
the ones the linker feels free to generate ?
Given that the vmlinux.lds scripts go into minute detail about
placement of sections in the kernel, why are we even letting the linker
store orphan sections? I think that all vmlinux.lds ought to end with
this.
/DISCARD/ : { *(*) } /* Discard all other sections */
If we want anything in the kernel then we put it there, and say where
we want it. Anything not explicitly listed is discarded. I just did
this with ix86 and vmlinux shrank by 9K, mainly in .bss. It would not
boot afterwards so obviously some part of that 9K is required but right
now it works by some "magic" storing the unknown sections. I'm going
to track down which sections are not being explicitly placed.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thu, 3 Aug 2000, Keith Owens wrote:
On Thu, 3 Aug 2000 11:58:36 +0200 (METDST),
Gabriel Paubert [off-list ref] wrote:
quoted
What I hate in all this is that the combination of 2 bugs (no
ksymtab/kstrtab in vmlinux.lds and no definition of the start and stop
symbols) ends up in something working through behind the scenes black
magic. Perhaps names should be chosen such that they will never clash with
the ones the linker feels free to generate ?
Given that the vmlinux.lds scripts go into minute detail about
placement of sections in the kernel, why are we even letting the linker
store orphan sections? I think that all vmlinux.lds ought to end with
this.
/DISCARD/ : { *(*) } /* Discard all other sections */
No problem.
If we want anything in the kernel then we put it there, and say where
we want it. Anything not explicitly listed is discarded. I just did
this with ix86 and vmlinux shrank by 9K, mainly in .bss. It would not
boot afterwards so obviously some part of that 9K is required but right
now it works by some "magic" storing the unknown sections. I'm going
to track down which sections are not being explicitly placed.
I have trouble parsing this, since the bss by definition does not occupy
any space in vmlinux.
objdump --head lists all the sections and it's quite easy to see which
ones have unexpected names (the orphans by definition). Also ppc
vmlinux.lds includes a lot of section which are probably never needed:
AFAICT the plt/got have no meaning in a statically linked image and the
ctors is C++ only. It needs a serious cleanup IMHO...
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
At 14:01 03.08.00, Gabriel Paubert wrote:
On Thu, 3 Aug 2000, Keith Owens wrote:
quoted
On Thu, 3 Aug 2000 11:58:36 +0200 (METDST),
Gabriel Paubert [off-list ref] wrote:
quoted
What I hate in all this is that the combination of 2 bugs (no
ksymtab/kstrtab in vmlinux.lds and no definition of the start and stop
symbols) ends up in something working through behind the scenes black
magic. Perhaps names should be chosen such that they will never clash with
the ones the linker feels free to generate ?
Given that the vmlinux.lds scripts go into minute detail about
placement of sections in the kernel, why are we even letting the linker
store orphan sections? I think that all vmlinux.lds ought to end with
this.
/DISCARD/ : { *(*) } /* Discard all other sections */
No problem.
quoted
If we want anything in the kernel then we put it there, and say where
we want it. Anything not explicitly listed is discarded. I just did
this with ix86 and vmlinux shrank by 9K, mainly in .bss. It would not
boot afterwards so obviously some part of that 9K is required but right
now it works by some "magic" storing the unknown sections. I'm going
to track down which sections are not being explicitly placed.
I have trouble parsing this, since the bss by definition does not occupy
any space in vmlinux.
objdump --head lists all the sections and it's quite easy to see which
ones have unexpected names (the orphans by definition). Also ppc
vmlinux.lds includes a lot of section which are probably never needed:
AFAICT the plt/got have no meaning in a statically linked image and the
ctors is C++ only. It needs a serious cleanup IMHO...
With newer binutils the tool I prefer for this is readelf -a.
Also note that binutils up to about 2.9.5.0.30 has a bug in the section
handling (which is still there in the official 2.10, but fixed in hjl's
releases). So for serious testing I would recommend to use
binutils-2.10.0.9 or 2.10.0.18 or later (?).
And if you plan to program the kernel into a flash, you'll need my
gcc-2.95.3-2c or later gcc, otherwise some data initialized by constructors
may wrongly end up in .rodata. Yes, gcc can produce constructors even in
plain C if you use some extensions (eg. some methods to init a struct),
which happen to be used in the kernel. So please keep the .ctors sections :-).
Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/