Re: linker bug?
On Tue, 3 Feb 2004, Geert Uytterhoeven wrote:
> On Sun, 30 Nov 2003, Geert Uytterhoeven wrote:
> > When trying to get modules working in 2.6.0-test11, I'm seeing something weird.
> > A kernel without module support boots fine, while a kernel with module support
> > crashes very early because any Chip RAM allocation fails.
> >
> > Some investigation shows that amiga_hw_present.CHIP_RAM is set initially, but
> > looses its value later. Apparently it's destroyed when mach_gettimeoffset is
> > filled in.
> >
> > System.map shows:
> > | 00180bf2 B amiga_hw_present
> > | 00180bf4 B mach_gettimeoffset
> >
> > I.e. amiga_hw_present is only 16 bits large, while it contains a bitfield of 32
> > single bit values. So when mach_gettimeoffset is changed, half of
> > amiga_hw_present is overwritten.
> >
> > I'm using cross gcc version 2.95.2 20000220 and cross binutils version 2.9.5
> > (with BFD 2.9.5.0.37), both built from Debian sources a while ago.
> >
> > Then I relinked the kernel using my newer cross binutils (2.13.90.0.10
> > 20021010, from Debian toolchain-source). System.map stills shows that
> > amiga_hw_present is only 2 bytes large.
> >
> > Then I recompiled arch/m68k/amiga/config.c using my newer cross gcc (3.2, from
> > Debian toolchain-source) and relinked (tried both binutils). System.map stills
> > shows that amiga_hw_present is only 2 bytes large.
> >
> > `nm -S arch/m68k/amiga/config.o' does show that amiga_hw_present has a size of
> > 4 bytes in all cases, so it looks like a linker bug.
> >
> > Anyone seen a similar problem before?
>
> Whatever linker[*] I use to link the final image, `nm -S vmlinux | sort' shows
> output like:
>
> | 0017f620 00000004 B m68k_memoffset *
> | 0017f621 00000001 B amiga_psfreq
> | 0017f622 00000004 B amiga_hw_present *
> | 0017f624 00000004 B mach_gettimeoffset *
> | 0017f626 00000070 b ram_resource *
> | 0017f628 00000004 B mach_reset
> | 0017f62c 00000100 b m68k_command_line *
> | 0017f674 000007d0 b nodes *
> | 0017f696 00000002 b jiffy_ticks
> | 0017f698 00000038 b ami_irq_list
> | 0017f6d0 00000040 b ami_ablecount
> | 0017f710 00000004 B amiga_chip_size
>
> As you can see, several objects (marked with an asterisk) are allocated less
> memory than their size indicates.
>
> [*] I tried 2.9.5, 2.13.90.0.10, 2.14.90.0.4 (all cross) and 2.14.90.0.7
> (native). All fail.
>
> If CONFIG_MODULES is not set, everything is OK (well, the kernel boots, and a
> quick look didn't reveal any too-small objects).
>
> Who should I bug with this problem? All binutils are from Debian (or compiled
> from Debian sources).
I just tried binutils from CVS (which is GNU ld version 2.14.90 20040204),
configured like this:
configure --target=m68k-linux --with-gnu-as --with-gnu-ld --disable-static
and it shows the exact same problem.
To let you reproduce the problem, I uploaded all object files and the linker
script to http://home.tvd.be/cr26864/ld_bug.tar.bz2. Just extract the archive,
and run the command in the file link-cmd:
m68k-linux-ld -m m68kelf -T arch_m68k_kernel_vmlinux.lds.s \
arch_m68k_kernel_head.o init_built-in.o --start-group usr_built-in.o \
arch_m68k_kernel_built-in.o arch_m68k_mm_built-in.o \
arch_m68k_amiga_built-in.o arch_m68k_fpsp040_built-in.o \
arch_m68k_ifpsp060_built-in.o kernel_built-in.o mm_built-in.o \
fs_built-in.o ipc_built-in.o security_built-in.o crypto_built-in.o \
lib_lib.a arch_m68k_lib_lib.a lib_built-in.o arch_m68k_lib_built-in.o \
drivers_built-in.o sound_built-in.o net_built-in.o --end-group \
.tmp_kallsyms2.o -o vmlinux
Then run `nm -S vmlinux | sort | less' and look at the adresses and sizes of
the variables mentioned above.
Thanks!
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
Reply to: