gcc+newlib cross compiler doesn't work for xscale

[Jeff Johnston]

XXXXXX wrote:
> 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
>

I am assuming you have built newlib in the same build directory as gcc and 
binutils.  Correct?

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

According to gdb, you are set up to be using an Angel monitor.  Is this correct 
for your board?  If you in fact have the Demon monitor or no monitor, then you 
have to go and manually edit newlib/configure.host and clean and rebuild newlib 
to set this up.  The following is an excerpt from configure.host:


# Select which debug protocol is being used.
# ARM_RDP_MONITOR selects the Demon monitor.
# ARM_RDI_MONITOR selects the Angel monitor.
# If neither are defined, then hard coded defaults will be used
# to create the program's environment.
# See also thumb below.
#       newlib_cflags="${newlib_cflags} -DARM_RDP_MONITOR"
         newlib_cflags="${newlib_cflags} -DARM_RDI_MONITOR"
         ;;


>    %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.
>

You shouldn't be doing this unless you have added pthread support.  Currently, 
pthread support in newlib is only supplied for x86 linux.  If you need this, 
then I suggest you look at adding arm support to the libc/sys/linux directory 
which means adding the various machine-dependent portions (e.g. syscall 
assembler sequence).

-- Jeff J.