This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
gcc+newlib cross compiler doesn't work for xscale
- From: "³ÂÓÀ½¡" <chenyj99 at mails dot tsinghua dot edu dot cn>
- To: newlib at sources dot redhat dot com
- Date: Fri, 30 Apr 2004 10:09:58 +0800
- Subject: gcc+newlib cross compiler doesn't work for xscale
- Reply-to: "³ÂÓÀ½¡" <chenyj99 at mails dot tsinghua dot edu dot cn>
Hi, all,
I've built up a gcc-newlibc tool chain for a xscale board(arm5l) using
binutils-2.13.90.0.16
gcc-3.2.1
newlib-1.12.0
target is arm-elf, main configuration options is
--enable-multilib --enable-interwork
and the t-arm-elf file is modified to enable thumb/thumb-interwork.
The main purpose is to enable thumb/interwork ability for the target. The
building process works fine, no errors occured. And the result gcc can compile
arm/thumb code.
But there are two problems.
1.the binaries just cannot run on the target board.
it's just like this:
// hello.c
#include <stdio.h>
int main(void) {
printf("hello world!\n");
return 0;
}
compiled with:
%arm-elf-gcc -o hello_arm hello.c
%arm-elf-gcc -mthumb -o hello_thumb hello.c
on the host machine ( an i686-linux machine), run the simulator:
%xscale-elf-run hello_arm
hello world!
%xscale-elf-run hello_thumb
hello world!
but on the target machine:
%hello_arm
Segmentation fault!
%hello_thumb
Segmentation fault!
gdb exposes the following information:
%gdb hello_arm
(...)
(gdb)run
Starting program: /home/yjchen/test/arm
Program received signal SIGSEGV, Segmentation fault.
0x0000812c in start ()
(gdb)disass 0x8120 0x8140
Dump of assembler code from 0x8120 to 0x8140:
0x8120 <start>: mov r0, #22 ; 0x16
0x8124 <start+4>: add r1, pc, #228 ; 0xe4
0x8128 <start+8>: swi 0x00123456
0x812c <start+12>: ldr r0, [pc, #220] ; 0x8210 <start+240>
0x8130 <start+16>: ldr sp, [r0, #8]
0x8134 <start+20>: ldr r10, [r0, #12]
0x8138 <start+24>: add r10, r10, #256 ; 0x100
0x813c <start+28>: mov r1, #0 ; 0x0
End of assembler dump.
(gdb)info reg
r0 0x16 22
r1 0x8210 33296
r2 0x0 0
r3 0x0 0
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0xbffffa50 -1073743280
r12 0x0 0
sp 0xbffffa50 -1073743280
lr 0x0 0
pc 0x812c 33068
fps 0x0 0
cpsr 0x10 16
The above lines of code comes from crt0.o, which is compiled from
newlib/glibc/sys/arm/crt0.S.
I don't catch the reason why this could happen. Can someone explain
it? Is this a problem of the gcc/newlib compilation configuration, or
merely a problem of the arm-linux?
two key points:
a. xscale simualtor run this code without error.
b. arm-linux compilation with gcc/glibc toolchain for pure arm
instructions works fine on the target board, without any error.
2. Can newlib support multithreads now?
I have compiled newlib using
--enable-newlib-multithread
but when gcc still in a single-thread mode.
%gcc -v
Reading specs from
/home/yjchen/nnewlib/install/lib/gcc-lib/arm-elf/3.2.1/specs
Configured with: /home/yjchen/src/gcc-3.2.1-2/configure --target=arm-elf
--prefix=/home/yjchen/nnewlib/install
--with-sysroot=/home/yjchen/nnewlib/install/arm-elf
--with-newlib
--with-headers=/home/yjchen/src/newlib-1.12.0/newlib/libc/include
--enable-newlib-multithread --enable-threads --with-cpu=xscale
--with-softfloat-support=internal --enable-languages=c,c++ --nfp
--enable-interwork --enable-multilib
Thread model: single
gcc version 3.2.1
Since the application want to build requires pthread support, how can
I achieve that?
I'm still trying to figure out which part goes wrong, but I think
suggestion from experience person should be more helpful.
Thanks.
Chen Yongjian