kernel-image-2.6.7

[ Background: M68k 2.6.x kernels with CONFIG_MODULES=y have been crashing very
early for me since quite a while. The problem seems to be incorrect addresses (and thus sizes) for various variables, causing data structure corruption ]

[ m68k_memory is supposed to be 32 bytes long, not 4 bytes ]

Indeed, in arch/m68k/kernel/setup.o .bss and .init.data become zero-sized, while all other sections have the same size.

If I do `make V=1 arch/m68k/kernel/setup.o', I get:

| anakin$ make V=1 arch/m68k/kernel/setup.o
| make -C /home/geert/linux/testing/linux-m68k-2.6.9-rc1 O=/home/geert/linux/testing/linux-m68k-2.6.x-amiga-mod arch/m68k/kernel/setup.o
| make -C /home/geert/linux/testing/linux-m68k-2.6.x-amiga-mod            \
| KBUILD_SRC=/home/geert/linux/testing/linux-m68k-2.6.9-rc1            KBUILD_VERBOSE=1   \
| KBUILD_CHECK= KBUILD_EXTMOD=""  \
|         -f /home/geert/linux/testing/linux-m68k-2.6.9-rc1/Makefile arch/m68k/kernel/setup.o
| make -f /home/geert/linux/testing/linux-m68k-2.6.9-rc1/scripts/Makefile.build obj=scripts/basic
| make -f /home/geert/linux/testing/linux-m68k-2.6.9-rc1/scripts/Makefile.build obj=scripts
| make -f /home/geert/linux/testing/linux-m68k-2.6.9-rc1/scripts/Makefile.build obj=scripts/genksyms
| make -f /home/geert/linux/testing/linux-m68k-2.6.9-rc1/scripts/Makefile.build obj=scripts/mod
| make -f /home/geert/linux/testing/linux-m68k-2.6.9-rc1/scripts/Makefile.build obj=arch/m68k/kernel arch/m68k/kernel/setup.o
|   m68k-linux-gcc -Wp,-MD,arch/m68k/kernel/.setup.o.d -nostdinc -iwithprefix include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/geert/linux/testing/linux-m68k-2.6.9-rc1/include -I/home/geert/linux/testing/linux-m68k-2.6.9-rc1/arch/m68k/kernel -Iarch/m68k/kernel -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -pipe -fno-strength-reduce -ffixed-a2 -m68040 -O2 -fomit-frame-pointer  -DKBUILD_BASENAME=setup -DKBUILD_MODNAME=setup -c -o arch/m68k/kernel/.tmp_setup.o /home/geert/linux/testing/linux-m68k-2.6.9-rc1/arch/m68k/kernel/setup.c
| anakin$

Note that according to the last line, m68k-linux-gcc will store its output in arch/m68k/kernel/.tmp_setup.o instead of arch/m68k/kernel/setup.o! But afterwards there is no arch/m68k/kernel/.tmp_setup.o, only arch/m68k/kernel/setup.o?

If I execute the m68k-linux-gcc command by hand, it does create
arch/m68k/kernel/.tmp_setup.o, and ... surprise! The sizes of the .bss and .init.data sections in that file are correct:

| anakin$ m68k-linux-objdump -h arch/m68k/kernel/.tmp_setup.o
|
| arch/m68k/kernel/.tmp_setup.o:     file format elf32-m68k
|
| Sections:
| Idx Name          Size      VMA       LMA       File off  Algn
|   0 .text         0000024a  00000000  00000000  00000034  2**2
|                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
|   1 .data         0000001a  00000000  00000000  00000280  2**2
|                   CONTENTS, ALLOC, LOAD, RELOC, DATA
|   2 .bss          00000188  00000000  00000000  0000029c  2**2
                    ^^^^^^^^
|                   ALLOC
|   3 .note         00000014  00000000  00000000  0000029c  2**0
|                   CONTENTS, READONLY
|   4 .init.data    00000008  00000000  00000000  000002b0  2**1
                    ^^^^^^^^
|                   CONTENTS, ALLOC, LOAD, DATA
|   5 __kcrctab     00000004  00000000  00000000  000002b8  2**1
|                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
|   6 __ksymtab_strings 0000000f  00000000  00000000  000002bc  2**0
|                   CONTENTS, ALLOC, LOAD, READONLY, DATA
|   7 __ksymtab     00000008  00000000  00000000  000002cc  2**1
|                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
|   8 .rodata       00000256  00000000  00000000  000002d4  2**0
|                   CONTENTS, ALLOC, LOAD, READONLY, DATA
|   9 .init.text    00000396  00000000  00000000  0000052a  2**1
|                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
|  10 .comment      0000002f  00000000  00000000  000008c0  2**0
|                   CONTENTS, READONLY
| anakin$

while .bss and .init.data are of size zero in arch/m68k/kernel/setup.o:

| anakin$ m68k-linux-objdump -h arch/m68k/kernel/setup.o
|
| arch/m68k/kernel/setup.o:     file format elf32-m68k
|
| Sections:
| Idx Name          Size      VMA       LMA       File off  Algn
|   0 .text         0000024a  00000000  00000000  00000034  2**2
|                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
|   1 __kcrctab     00000004  00000000  00000000  0000027e  2**1
|                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
|   2 __ksymtab_strings 0000000f  00000000  00000000  00000282  2**0
|                   CONTENTS, ALLOC, LOAD, READONLY, DATA
|   3 __ksymtab     00000008  00000000  00000000  00000292  2**1
|                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
|   4 .rodata       00000256  00000000  00000000  0000029a  2**0
|                   CONTENTS, ALLOC, LOAD, READONLY, DATA
|   5 .init.text    00000396  00000000  00000000  000004f0  2**1
|                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
|   6 .data         0000001a  00000000  00000000  00000888  2**2
|                   CONTENTS, ALLOC, LOAD, RELOC, DATA
|   7 .bss          00000000  00000000  00000000  000008a4  2**2
                    ^^^^^^^^
|                   ALLOC
|   8 .init.data    00000000  00000000  00000000  000008a4  2**1
                    ^^^^^^^^
|                   CONTENTS, ALLOC, LOAD, DATA
|   9 .note         00000014  00000000  00000000  000008a4  2**0
|                   CONTENTS, READONLY
|  10 .comment      0000002f  00000000  00000000  000008b8  2**0
|                   CONTENTS, READONLY
| anakin$

Now the remaining questions are:
1. Why does kbuild create arch/m68k/kernel/.tmp_setup.o?
2. How does kbuild create setup.o from .tmp_setup.o, destroying .bss and

     .init.data?

3. Why doesn't the above step show up with `make V=1'?

[ digging into scripts/Makefile.build ]

Aha, kbuild does this only if CONFIG_MODVERSIONS=y.

So it goes wrong during this step:

| m68k-linux-ld -r -o x.o arch/m68k/kernel/.tmp_setup.o -T \
| arch/m68k/kernel/.tmp_setup.ver

| anakin$ cat arch/m68k/kernel/.tmp_setup.ver
| __crc_mach_heartbeat = 0x39638af7 ;
| anakin$

Does the above look like a valid linker file? `mach_heartbeat' is indeed the only exported symbol in arch/m68k/kernel/setup.c.

[ disabling CONFIG_MODVERSIONS ]

And now .bss and .initdata are OK as well... Let's see whether the resulting kernel works...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Looks correct. If anything goes wrong then it must be the ld -r call.

Andreas.

Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Not good.. Se below.

A bit code from Makefile.build:
cmd_modversions = \

if ! $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then	\
	mv $(@D)/.tmp_$(@F) $@;					\
else								\
	$(CPP) -D__GENKSYMS__ $(c_flags) $<			\
	| $(GENKSYMS)						\
	> $(@D)/.tmp_$(@F:.o=.ver);				\
								\
	$(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F) 		\
		-T $(@D)/.tmp_$(@F:.o=.ver);			\
	rm -f $(@D)/.tmp_$(@F) $(@D)/.tmp_$(@F:.o=.ver);	\

fi;

First part checks if there is any exported symbols - which we have in this case. The $(CPP) and $(GENKSYMS) part finds exported symbols and creates the .ver file. Your .ver file looked fine - so this step has succeded..
Then we do the linking.

Could you try to stuff in an echo line here - something like:

	echo  $(LD) $(LDFLAGS) 					\
        $(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F)              \
                -T $(@D)/.tmp_$(@F:.o=.ver);                    \

Just to be confirmed that there is no LDFLAGS that fouls us here.

Otherwise I have no good suggestions.

Sam

And LDFLAGS doesn't foul us here (it's just `-m m68kelf').

Just for those that are interested: after some more digging this turned out to be a bug in the (old) binutils I'm using. It got fixed in later releases of binutils. (Originally I thought the problem was introduced during the final linking step of the kernel, and it showed up with whatever version of ld I used for the final linking step).

How to reproduce:

| anakin$ cat test.s
|         .version        "01.01"
| .section        .bss
| m68k_memory:
|         .zero   32
| anakin$

The key is the `.version' keyword, without that the problem cannot be reproduced.

| anakin$ cat test.ver
| anakin$

Yep, an empty linker script is fine. Without a linker script it cannot be reproduced, though.

Results for dfferent versions of binutils:

| anakin$ m68k-linux-as -o test.o test.s && m68k-linux-ld -r -o test2.o test.o -T test.ver && m68k-linux-objdump -h test*.o | grep bss; m68k-linux-ld -V
|   2 .bss          00000020  00000000  00000000  00000034  2**2
|   2 .bss          00000000  00000000  00000000  00000034  2**2
                    ^^^^^^^^

BUG! .bss becomes zero sized!

| GNU ld version 2.9.5 (with BFD 2.9.5.0.37)
|   Supported emulations:
|    m68kelf
|    m68klinux
| anakin$

And newer binutils are fine:

| tux$ m68k-linux-as -o test.o test.s && m68k-linux-ld -r -o test2.o test.o -T test.ver && m68k-linux-objdump -h test*.o | grep bss; m68k-linux-ld -V
|   2 .bss          00000020  00000000  00000000  00000034  2**2
|   2 .bss          00000020  00000000  00000000  00000034  2**2
| GNU ld version 2.13.90.0.10 20021010
|   Supported emulations:
|    m68kelf
|    m68klinux
| tux$

| anakin$ m68k-linux-as -o test.o test.s && m68k-linux-ld -r -o test2.o test.o -T test.ver && m68k-linux-objdump -h test*.o | grep bss; m68k-linux-ld -V
|   2 .bss          00000020  00000000  00000000  00000034  2**2
|   2 .bss          00000020  00000000  00000000  00000034  2**2
| GNU ld version 2.14.90.0.7 20031029 Debian GNU/Linux
|   Supported emulations:
|    m68kelf
|    m68klinux
| anakin$

Conclusions: gcc 2.95.2 and binutils 2.9.5 are fine for compiling 2.6.x kernels for m68k, but:
- You need a newer binutils for building initramfs (make usr/)
- You need a newer binutils for building modular kernels with CONFIG_MODVERSIONS=y

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Is this something you can make a check for in arch/m68k/Makefile? Just so others don't hit the same trap..

Sam

Probably. But please note that the first item doesn't need an explicit check, since as will just error out when not recognizing the .incbin keyword.

About the second item, I don't know whether there are binutils versions that have the ld bug, but do implement .incbin in as. If these don't exist, no such test is necessary.

So it's just the people (like me :-) who work around installing a new version of binutils that got hit...

The reason I'm still using gcc 2.95.2 is that 3.2 gives ICEs on some source files.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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