From: Stuart M. <stu...@st...> - 2002-05-28 20:35:02
|
Folks Given the time it takes to boot a kernel using gdb, I thought I'd have a go at getting the compressed kernel to work. Unfortuntaly it appears to have exposed a bug in binutils. The way in which the compressed kernel image is typically generated is that we use ld to generate a ELF file, which contains a single section, the contents of which come from a binary file: % more piggy.lnk SECTIONS { .image : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; }} % sh4-linux-ld -EL -r -o piggy.o -b binary piggy.gz -b elf32-sh-linux -T piggy.lnk % ls -l piggy.gz piggy.o -rw-r--r-- 1 stuart users 631802 May 28 19:40 piggy.gz -rw-r--r-- 1 stuart users 632401 May 28 21:08 piggy.o Unfortuntaly when I try this using the sh64 ld from the 20020410 release it segfaults: % sh64-superh-linux-gnu-ld -EL -r -o piggy.o -b binary piggy.gz -b elf32-sh64-linux -T piggy.lnk zsh: segmentation fault (core dumped) sh64-superh-linux-gnu-ld -EL -r -o piggy.o -b binary piggy.gz -b - % gdb sh64-superh-linux-gnu-ld core ... (gdb) where #0 0x805a292 in sh64_elf_shlelf32_linux_before_allocation () at eshlelf32_linux.c:198 #1 0x80583f4 in ldemul_before_allocation () at /vob/sh5binutils.cmp/src/ld/ldemul.c:78 #2 0x8052916 in lang_process () at /vob/sh5binutils.cmp/src/ld/ldlang.c:4089 #3 0x8054d4e in main (argc=12, argv=0xbffff5e4) at /vob/sh5binutils.cmp/src/ld/ldmain.c:347 #4 0x4003aa7c in __libc_start_main (main=0x8054820 <main>, argc=12, ubp_av=0xbffff5e4, init=0x80490bc <_init>, fini=0x80ad8c0 <_fini>, rtld_fini=0x4000d684 <_dl_fini>, stack_end=0xbffff5dc) at ../sysdeps/generic/libc-start.c:111 Any ideas which is going wrong? I was hoping I might be able to use the SH4 tools just to generate the piggy.o object file, but unfortuntaly when I try to link this to an object file containing real code I get the message: piggy.o: uses non-SH64 instructions while previous module uses SH64 instructions Bad value: failed to merge target specific data of file piggy.o Not unreasonable in general, but in this case it shouldn't be a problem I'd have thought. As a work around, could we fudge this somehow? Thanks Stuart -- Stuart Menefy stu...@st... STMicroelectronics Ltd ST Intranet: mo.bri.st.com Bristol, UK Rest of the World: www.linuxsh.st.com |