Re: 2.5.42 broke ARM zImage/Image

From: Russell King (rmk@arm.linux.org.uk)
Date: Mon Oct 14 2002 - 18:22:43 EST


Sam & Kai, lkml and others who join us on this happy day.

As well intentioned as your efforts are, and as patient as you are, I
don't believe we're going to solve this one with the way things now
stand in kbuild.

Everything appears to work correctly with Sam's latest patch. However,
there is one fundamental problem that looks like it's impossible to
solve. Here's the relevant fragment of Sam's patch:

===== arch/arm/boot/compressed/Makefile 1.10 vs edited =====
--- 1.10/arch/arm/boot/compressed/Makefile Sun Oct 13 12:22:02 2002
+++ edited/arch/arm/boot/compressed/Makefile Mon Oct 14 22:15:08 2002
@@ -65,35 +63,39 @@
 OBJS += head-xscale.o
 endif
 
-SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/LOAD_ADDR/$(ZRELADDR)/;s/BSS_START/$(ZBSSADDR)/
+SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/LOAD_ADDR/$(ZRELADDR)/;\
+s/BSS_START/$(ZBSSADDR)/;s#OBJ#$(obj)#
 
-LIBGCC := $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)
+EXTRA_TARGETS := vmlinux piggy.o font.o head.o $(OBJS)
+EXTRA_CFLAGS := $(CFLAGS_BOOT) -fpic
+EXTRA_AFLAGS := -traditional
 
-all: vmlinux
+include $(TOPDIR)/Rules.make
 
-vmlinux: $(HEAD) $(OBJS) piggy.o vmlinux.lds
- $(LD) $(ZLDFLAGS) $(HEAD) $(OBJS) piggy.o $(LIBGCC) -o vmlinux
+LDFLAGS_vmlinux := -p -X -T $(obj)/vmlinux.lds \
+ $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)
 
-$(HEAD): $(HEAD:.o=.S)
- $(CC) $(AFLAGS) -traditional -c $(HEAD:.o=.S)
+$(obj)/vmlinux: $(obj)/$(HEAD) $(obj)/piggy.o $(obj)/vmlinux.lds \
+ $(addprefix $(obj)/, $(OBJS))
+ $(call if_changed,ld)

So we end up with the following to link the decompressor vmlinux:

LDFLAGS_vmlinux := -p -X -T $(obj)/vmlinux.lds \
        $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)

$(obj)/vmlinux: $(obj)/$(HEAD) $(obj)/piggy.o $(obj)/vmlinux.lds \
                $(addprefix $(obj)/, $(OBJS))
        $(call if_changed,ld)

When linking vmlinux for the decompressor, we use the following linker
script:

OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
...
  .text : {
    input_data = .;
    arch/arm/boot/compressed/piggy.o
    input_data_end = .;
    . = ALIGN(4);
  }
...
}

which directs the linker to place arch/arm/boot/compressed/piggy.o
between two symbols, input_data and input_data_end. However, in
practice, we actually get the following:

  ld -p -X -T arch/arm/boot/compressed/vmlinux.lds
 /usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.3/libgcc.a
 arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o
 arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/misc.o
 arch/arm/boot/compressed/head-sa1100.o -o arch/arm/boot/compressed/vmlinux

00082b5c t lbits
00082b60 t dbits
00082b9c t p.687
00082d80 T _binary_arch_arm_boot_compressed_piggy_gz_start
000c1713 A _binary_arch_arm_boot_compressed_piggy_gz_size
00144493 T _binary_arch_arm_boot_compressed_piggy_gz_end
00144494 T _start
00144494 T input_data
00144494 T input_data_end

Changing the path in the vmlinux.lds.in script makes the linker
correctly complain that the object isn't found, so it is using
it:

  ld -p -X -T arch/arm/boot/compressed/vmlinux.lds
 /usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.3/libgcc.a
 arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o
 arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/misc.o
 arch/arm/boot/compressed/head-sa1100.o -o arch/arm/boot/compressed/vmlinux

ld: cannot open piggy.o: No such file or directory

Removing the object from the linker command line, but leaving it
in the script results in the same object file layout - in other
words, the linker isn't doing what its being told:

  ld -p -X -T arch/arm/boot/compressed/vmlinux.lds
 /usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.3/libgcc.a
 arch/arm/boot/compressed/head.o arch/arm/boot/compressed/vmlinux.lds
 arch/arm/boot/compressed/misc.o arch/arm/boot/compressed/head-sa1100.o
 -o arch/arm/boot/compressed/vmlinux

00082b5c t lbits
00082b60 t dbits
00082b9c t p.687
00082d80 T _binary_arch_arm_boot_compressed_piggy_gz_start
000c1713 A _binary_arch_arm_boot_compressed_piggy_gz_size
00144493 T _binary_arch_arm_boot_compressed_piggy_gz_end
00144494 T _start
00144494 T input_data
00144494 T input_data_end

So I decided to see how x86 does it, and tried it on ARM:

  ld -r -b binary --oformat elf32-littlearm -T
 arch/arm/boot/compressed/piggy.lds arch/arm/boot/compressed/piggy.gz
 -o arch/arm/boot/compressed/piggy.o
  ld -p -X -T arch/arm/boot/compressed/vmlinux.lds
 /usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.3/libgcc.a
 arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.o
 arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/misc.o
 arch/arm/boot/compressed/head-sa1100.o -o arch/arm/boot/compressed/vmlinux
ld: Error: arch/arm/boot/compressed/piggy.o uses hard floating point, whereas arch/arm/boot/compressed/vmlinux uses soft floating point
File format not recognized: failed to merge target specific data of file arch/arm/boot/compressed/piggy.o

So, basically, I'm screwed at the moment, unless someone has anything
else to suggest.

If there isn't anything else, I'm going to have to call for the
re-implementation of the make -C method that Kai originally had
in his patch.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:52 EST