* Re: kernel-image-2.6.7 [not found] ` <Pine.GSO.4.58.0408230947190.29370@waterleaf.sonytel.be> @ 2004-08-25 20:50 ` Geert Uytterhoeven 2004-08-25 22:17 ` kernel-image-2.6.7 Andreas Schwab 2004-08-26 19:56 ` kernel-image-2.6.7 Sam Ravnborg 0 siblings, 2 replies; 6+ messages in thread From: Geert Uytterhoeven @ 2004-08-25 20:50 UTC (permalink / raw) To: Roman Zippel, Sam Ravnborg Cc: Christian T. Steigies, Linux/m68k, Linux Kernel Development [ 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 ] On Mon, 23 Aug 2004, Geert Uytterhoeven wrote: > On Sun, 22 Aug 2004, Roman Zippel wrote: > > Geert Uytterhoeven wrote: > > > Easily explained by System.map: > > > | 00194090 B amiga_model > > > | 00194090 B m68k_memory > > > | 00194094 B amiga_chipset > > > > > > So initializing amiga_model kills m68k_memory... [ m68k_memory is supposed to be 32 bytes long, not 4 bytes ] > > Anyway, I still can't reproduce this, but from the object files I've > > seen, it seems the bss isn't correctly set. Could you please check the > > various object files under arch/m68k/{kernel,amiga} for their bss size? > > At first sight, there seem to be more of them with a zero bss if > CONFIG_MODULES=y. Will be investigated... 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 -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel-image-2.6.7 2004-08-25 20:50 ` kernel-image-2.6.7 Geert Uytterhoeven @ 2004-08-25 22:17 ` Andreas Schwab 2004-08-26 19:56 ` kernel-image-2.6.7 Sam Ravnborg 1 sibling, 0 replies; 6+ messages in thread From: Andreas Schwab @ 2004-08-25 22:17 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Roman Zippel, Sam Ravnborg, Christian T. Steigies, Linux/m68k, Linux Kernel Development Geert Uytterhoeven <geert@linux-m68k.org> writes: > 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. Looks correct. If anything goes wrong then it must be the ld -r call. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de 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." ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel-image-2.6.7 2004-08-25 20:50 ` kernel-image-2.6.7 Geert Uytterhoeven 2004-08-25 22:17 ` kernel-image-2.6.7 Andreas Schwab @ 2004-08-26 19:56 ` Sam Ravnborg 2004-08-29 11:38 ` kernel-image-2.6.7 Geert Uytterhoeven 1 sibling, 1 reply; 6+ messages in thread From: Sam Ravnborg @ 2004-08-26 19:56 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Roman Zippel, Sam Ravnborg, Christian T. Steigies, Linux/m68k, Linux Kernel Development On Wed, Aug 25, 2004 at 10:50:36PM +0200, Geert Uytterhoeven wrote: > Indeed, in arch/m68k/kernel/setup.o .bss and .init.data become zero-sized, > while all other sections have the same size. Not good.. Se below. > > 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$ 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel-image-2.6.7 2004-08-26 19:56 ` kernel-image-2.6.7 Sam Ravnborg @ 2004-08-29 11:38 ` Geert Uytterhoeven 2004-08-29 12:11 ` kernel-image-2.6.7 Sam Ravnborg 0 siblings, 1 reply; 6+ messages in thread From: Geert Uytterhoeven @ 2004-08-29 11:38 UTC (permalink / raw) To: Sam Ravnborg Cc: Roman Zippel, Christian T. Steigies, Linux/m68k, Linux Kernel Development On Thu, 26 Aug 2004, Sam Ravnborg wrote: > 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. 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 -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel-image-2.6.7 2004-08-29 11:38 ` kernel-image-2.6.7 Geert Uytterhoeven @ 2004-08-29 12:11 ` Sam Ravnborg 2004-08-30 8:53 ` kernel-image-2.6.7 Geert Uytterhoeven 0 siblings, 1 reply; 6+ messages in thread From: Sam Ravnborg @ 2004-08-29 12:11 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Sam Ravnborg, Roman Zippel, Christian T. Steigies, Linux/m68k, Linux Kernel Development On Sun, Aug 29, 2004 at 01:38:02PM +0200, Geert Uytterhoeven wrote: > 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 Is this something you can make a check for in arch/m68k/Makefile? Just so others don't hit the same trap.. Sam ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel-image-2.6.7 2004-08-29 12:11 ` kernel-image-2.6.7 Sam Ravnborg @ 2004-08-30 8:53 ` Geert Uytterhoeven 0 siblings, 0 replies; 6+ messages in thread From: Geert Uytterhoeven @ 2004-08-30 8:53 UTC (permalink / raw) To: Sam Ravnborg Cc: Roman Zippel, Christian T. Steigies, Linux/m68k, Linux Kernel Development On Sun, 29 Aug 2004, Sam Ravnborg wrote: > On Sun, Aug 29, 2004 at 01:38:02PM +0200, Geert Uytterhoeven wrote: > > 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 > > Is this something you can make a check for in arch/m68k/Makefile? > Just so others don't hit the same trap.. 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 -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-08-30 8:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20040809073126.GA4669@skeeve>
[not found] ` <Pine.LNX.4.58.0408221129590.25793@anakin>
[not found] ` <Pine.LNX.4.58.0408221145090.25793@anakin>
[not found] ` <20040822101914.GA7480@skeeve>
[not found] ` <Pine.GSO.4.58.0408221224310.12638@waterleaf.sonytel.be>
[not found] ` <Pine.LNX.4.58.0408221333460.13834@anakin>
[not found] ` <4128C3F4.6070507@linux-m68k.org>
[not found] ` <Pine.GSO.4.58.0408230947190.29370@waterleaf.sonytel.be>
2004-08-25 20:50 ` kernel-image-2.6.7 Geert Uytterhoeven
2004-08-25 22:17 ` kernel-image-2.6.7 Andreas Schwab
2004-08-26 19:56 ` kernel-image-2.6.7 Sam Ravnborg
2004-08-29 11:38 ` kernel-image-2.6.7 Geert Uytterhoeven
2004-08-29 12:11 ` kernel-image-2.6.7 Sam Ravnborg
2004-08-30 8:53 ` kernel-image-2.6.7 Geert Uytterhoeven
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®