linuxsh-shmedia-dev — Linux kernel development for the SHmedia architecture

Re: [linuxsh-shmedia-dev] binutils problem

[David M. <dav...@st...>]

stu...@st... wrote:

> 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?
> 

This sounds very similar to the problems I had building the 2.4.19 kernel, I think the linker
is too rigorous in checking what the machine type it is linking against. I had to pull some
directories from the kernel build in order to get it through, pending a toolchain fix. See the 
BK log on 2.4.19 for details.


-- 
Dave McKay 
Software Engineer STMicroelectronics
Email: dav...@st...

[linuxsh-shmedia-dev] binutils problem

[Stuart M. <stu...@st...>]

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

[linuxsh-shmedia-dev] Starting work on the PCI bridging code

[Gaster, B. <ben...@su...>]

Hi Dave/Stuart,
=20
We are planning to start work on the PCI bridging code and Silvano
thought that it would probably be a good idea to start from the
re-baselined kernel sources, which he thought Dave was close to having
completed.=20
=20
When do you expect that the rebase sources will appear in bitkepper?
=20
Thanks,
=20
ben.
=20