Where does ppc define __start___ksymtab?

Where does ppc define __start___ksymtab?

[Keith Owens]

Please cc: kaos@ocs.com.au on replies, I am not on this list.

I have been trying to find where ppc defines __start___ksymtab and
__stop___ksymtab symbols.  These delimit the __ksymtab entries for
module symbols.  On every other architecture that supports modules,
arch/xxx/vmlinux.lds contains lines like this

  __start___ksymtab = .;	/* Kernel symbol table */
  __ksymtab : { *(__ksymtab) }
  __stop___ksymtab = .;

I can find no equivalent lines for ppc in a stock 2.4.0-test5 source
tree yet ppc obviously defines them somewhere.  But where?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Geert Uytterhoeven]

On Tue, 1 Aug 2000, Keith Owens wrote:
> Please cc: kaos@ocs.com.au on replies, I am not on this list.
>
> I have been trying to find where ppc defines __start___ksymtab and
> __stop___ksymtab symbols.  These delimit the __ksymtab entries for
> module symbols.  On every other architecture that supports modules,
> arch/xxx/vmlinux.lds contains lines like this
>
>   __start___ksymtab = .;	/* Kernel symbol table */
>   __ksymtab : { *(__ksymtab) }
>   __stop___ksymtab = .;
>
> I can find no equivalent lines for ppc in a stock 2.4.0-test5 source
> tree yet ppc obviously defines them somewhere.  But where?

I'm no gcc linkscript expert, but doesn't the absence of __ksymtab stuff in
vmlinux.lds simply mean that gcc can put stuff for section __ksymtab wherever
it wants in the final object file?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Gabriel Paubert]

On Wed, 2 Aug 2000, Geert Uytterhoeven wrote:

>
> On Tue, 1 Aug 2000, Keith Owens wrote:
> > Please cc: kaos@ocs.com.au on replies, I am not on this list.
> >
> > I have been trying to find where ppc defines __start___ksymtab and
> > __stop___ksymtab symbols.  These delimit the __ksymtab entries for
> > module symbols.  On every other architecture that supports modules,
> > arch/xxx/vmlinux.lds contains lines like this
> >
> >   __start___ksymtab = .;	/* Kernel symbol table */
> >   __ksymtab : { *(__ksymtab) }
> >   __stop___ksymtab = .;
> >
> > I can find no equivalent lines for ppc in a stock 2.4.0-test5 source
> > tree yet ppc obviously defines them somewhere.  But where?
>
> I'm no gcc linkscript expert, but doesn't the absence of __ksymtab stuff in
> vmlinux.lds simply mean that gcc can put stuff for section __ksymtab wherever
> it wants in the final object file?

Not exactly, it will use the read/write/exec attributes to match the area
and it will actually place kstrtab and ksymtab just after .rodata in the
case of the ppc kernel. So it's not completely random, but sometimes hard
to predict (if it does not find anything that matches, it will place it at
the end).

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Keith Owens]

On Wed, 2 Aug 2000 22:18:08 +0200 (CEST),
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>On Tue, 1 Aug 2000, Keith Owens wrote:
>> Please cc: kaos@ocs.com.au on replies, I am not on this list.
>>
>> I have been trying to find where ppc defines __start___ksymtab and
>> __stop___ksymtab symbols.
>
>I'm no gcc linkscript expert, but doesn't the absence of __ksymtab stuff in
>vmlinux.lds simply mean that gcc can put stuff for section __ksymtab wherever
>it wants in the final object file?

Placement was not the problem.  It was the "magic" definition of
__start___ksymtab and __stop___ksymtab that had me baffled.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Paul Mackerras]

> I have been trying to find where ppc defines __start___ksymtab and
> __stop___ksymtab symbols.  These delimit the __ksymtab entries for
> module symbols.  On every other architecture that supports modules,
> arch/xxx/vmlinux.lds contains lines like this
>
>   __start___ksymtab = .;	/* Kernel symbol table */
>   __ksymtab : { *(__ksymtab) }
>   __stop___ksymtab = .;
>
> I can find no equivalent lines for ppc in a stock 2.4.0-test5 source
> tree yet ppc obviously defines them somewhere.  But where?

I think they must be defined automagically by the linker.  They aren't
defined explicitly anywhere but we still end up with a __ksymtab
section with the __start___ksymtab and __stop___ksymtab symbols
defined at the beginning and end of it.

We can add those lines if you like, that's no problem.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Keith Owens]

On Thu, 3 Aug 2000 16:13:46 +1000 (EST),
Paul Mackerras <paulus@linuxcare.com.au> wrote:
>> I have been trying to find where ppc defines __start___ksymtab and
>> __stop___ksymtab symbols.  These delimit the __ksymtab entries for
>> module symbols.  On every other architecture that supports modules,
>> arch/xxx/vmlinux.lds contains lines like this
>>
>>   __start___ksymtab = .;	/* Kernel symbol table */
>>   __ksymtab : { *(__ksymtab) }
>>   __stop___ksymtab = .;
>>
>> I can find no equivalent lines for ppc in a stock 2.4.0-test5 source
>> tree yet ppc obviously defines them somewhere.  But where?
>
>I think they must be defined automagically by the linker.  They aren't
>defined explicitly anywhere but we still end up with a __ksymtab
>section with the __start___ksymtab and __stop___ksymtab symbols
>defined at the beginning and end of it.
>
>We can add those lines if you like, that's no problem.

Please add them.  It makes the ppc vmlinux.lds more consistent with the
other archs that support modules.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Gabriel Paubert]

On Thu, 3 Aug 2000, Keith Owens wrote:

>
> On Thu, 3 Aug 2000 16:13:46 +1000 (EST),
> Paul Mackerras <paulus@linuxcare.com.au> wrote:
> >> I have been trying to find where ppc defines __start___ksymtab and
> >> __stop___ksymtab symbols.  These delimit the __ksymtab entries for
> >> module symbols.  On every other architecture that supports modules,
> >> arch/xxx/vmlinux.lds contains lines like this
> >>
> >>   __start___ksymtab = .;	/* Kernel symbol table */
> >>   __ksymtab : { *(__ksymtab) }
> >>   __stop___ksymtab = .;
> >>
> >> I can find no equivalent lines for ppc in a stock 2.4.0-test5 source
> >> tree yet ppc obviously defines them somewhere.  But where?
> >
> >I think they must be defined automagically by the linker.  They aren't
> >defined explicitly anywhere but we still end up with a __ksymtab
> >section with the __start___ksymtab and __stop___ksymtab symbols
> >defined at the beginning and end of it.
> >
> >We can add those lines if you like, that's no problem.
>
> Please add them.  It makes the ppc vmlinux.lds more consistent with the
> other archs that support modules.
>

Indeed they are automagically defined by the linker, which adds these
symbols to "orphan" section, i.e., the ones which are not explicitly
loaded (or discarded) in the linker script. The code that does all this
magic is somehat hidden in binutils/ld/emultempl/elf32.em.

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 ?

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Keith Owens]

On Thu, 3 Aug 2000 11:58:36 +0200 (METDST),
Gabriel Paubert <paubert@iram.es> 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/

Re: Where does ppc define __start___ksymtab?

[Gabriel Paubert]

On Thu, 3 Aug 2000, Keith Owens wrote:

> On Thu, 3 Aug 2000 11:58:36 +0200 (METDST),
> Gabriel Paubert <paubert@iram.es> 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 */

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/

Re: Where does ppc define __start___ksymtab?

[Keith Owens]

On Thu, 3 Aug 2000 14:01:44 +0200 (METDST),
Gabriel Paubert <paubert@iram.es> wrote:
>On Thu, 3 Aug 2000, Keith Owens wrote:
>> 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.

It is wierd.  Even though arch/i386/vmlinux.lds contains
".bss : { *(.bss) }", something extra is getting stored in .bss.  The
data has the same attributes as .bss, ALLOC only, alignment 2**5 but
its section name is not ".bss".  Adding

  .note : { *(.note) }
  .rest : { *(*) }

to the end of an otherwise untouched arch/i386/vmlinux.lds changes
vmlinux from this

 14 .bss          0003bb8c  c02a6c40  c02a6c40  001a7c40  2**5
                  ALLOC
 15 .comment      000044a0  00000000  00000000  001a7c40  2**0
                  CONTENTS, READONLY
 16 .note         00001680  c02e27cc  c02e27cc  001ac0e0  2**0
                  CONTENTS, READONLY

to this

 14 .bss          00014240  c02a6c40  c02a6c40  001a7c40  2**5
                  ALLOC
 15 .comment      000044a0  00000000  00000000  001a7c40  2**0
                  CONTENTS, READONLY
 16 .note         00001680  c02bae80  c02bae80  001ac0e0  2**0
                  CONTENTS, READONLY
 17 .rest         0002794c  c02bae80  c02bae80  001a7c40  2**5
                  ALLOC

Which is a lot more than 9K of unknown data.  I was looking at the on
disk size which contains the .note section, however removing that
should only shrink by 4K so I do not understand why vmlinux shrank by
9K.  The final step on i386 removes .note and
.comment from the bootable kernel anyway.

I'm trying to track down where the extra .bss like data is coming from.
I will mail the list when I find something.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Gabriel Paubert]

On Thu, 3 Aug 2000, Keith Owens wrote:

> On Thu, 3 Aug 2000 14:01:44 +0200 (METDST),
> Gabriel Paubert <paubert@iram.es> wrote:
> >On Thu, 3 Aug 2000, Keith Owens wrote:
> >> 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.
>
> It is wierd.

Indeed, Try to generate a linker map, it should help you tracking these
phantoms. In my Makefile for the prepboot bootloader (not yet
in the official kernel, not even bk tree), I have the following:


zImage: $(OBJECTS) $(IMAGES) ppcboot.lds
        $(OBJCOPY) $(TOPDIR)/vmlinux vmlinux -R .comment -S -K _start -K _end
        $(LD) -o zImage $(OBJECTS) --just-symbols=vmlinux \
        -b binary $(IMAGES) -T ppcboot.lds -Map zImage.map
					   ^^^^^^^^^^^^^^^
        rm vmlinux

and the .bss in zImage.map for my zImage looks like:

.bss            0x000b8320     0x1134
 *(.sbss)
 .sbss          0x000b8320       0x10 zlib.o
 *(.bss)
 .bss           0x000b8330     0x1090 zlib.o
                0x000b93c0                .=ALIGN(0x4)
 COMMON         0x000b93c0       0x94 em86.o
                                  0x0 (size before relaxing)
                0x000b93c0                v86_private
                0x0000044d                __bss_words=(SIZEOF(.bss)>>=0x2)
                0x000b8000

These might be the COMMON sections then.

	Gabriel.

P.S: I just received you other mail while finishing this, so my guess was
right. But generating a map is still a useful trick when you are lost in a
linker script (been there, done that).


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Keith Owens]

Keith Owens wrote
>I'm trying to track down where the extra .bss like data is coming from.
>I will mail the list when I find something.

It turned out to be COMMON.  Adding "*(COMMON)" to the .bss definition
put everything back to the original size.  That just means that
arch/i386/vmlinux.lds is well tuned already, no orphan sections.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Where does ppc define __start___ksymtab?

[Franz Sirl]

At 14:01 03.08.00, Gabriel Paubert wrote:

>On Thu, 3 Aug 2000, Keith Owens wrote:
>
> > On Thu, 3 Aug 2000 11:58:36 +0200 (METDST),
> > Gabriel Paubert <paubert@iram.es> 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 */
>
>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...

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/