Simple C Programs On Big-endian Xscale

[linnuxxy]

Im trying to develop programs to a target machine wth the following /proc/cpuinfo:

Processor : XScale-IXP4xx/IXC11xx rev 1 (v5b)
BogoMIPS : 266.24
Features : swp half thumb fastmult edsp

Hardware : iDirect Phoenix Platform
Revision : 0000
Serial : 0000000000000000

and uname -a:
Linux iDirect 2.4.24-uc0-iDirect0 #1 Fri Apr 29 16:01:03 GMT 2005 armv5b unknown

as it is Bigendian machine i use
/usr/local/arm-uclinux-tools2/arm-uclinux-elf/bin/atic -mbig-endian

to compile

the hello world is working fine.

i tired to compile a simple program

#include <stdio.h>

int main() {
printf("Hi: %d\n",0);
return 0;
}
the program had compiled well, but when i run the program on the target machine alot of rabush is showed out.

running the following program on the target shows "Segmentation fault" error
#include <stdio.h>

int main() {
char txt[]="Hi from Ahmad!\n";
sprintf(txt,"Hi: %d",0);
printf(txt);
return 0;
}
What is wrong and how to overcome this problem??!!
please help me!!

[lardman]

the program had compiled well, but when i run the program on the target machine alot of rabush is showed out.

Can you show us some of the output please?

Unless people here have experience with endian issues they won't be able to help except by logical reasoning (as all Zaurii run in littleendian mode, so I've never seen anything like this before).

You might get more exposure for this question by posting it to: http://www.arm.linux.org.uk/ (it's not Zaurus or Openembedded related yet). I'd also read the mailing list archives and see whether other people have experienced anything similar - search for bigendian.

But if anyone can help, then please chip in,


Si

[linnuxxy]

I can narrow the problem;
after asking.. it sounds like a bug in the toolchain... which have been batched out

Can anyone show me where to find a tested toolchain to compile to armeb (armv5b) architecture???

[lardman]

Not likely from us as we are all littleendian.

I was asking about the output as if the code thought it was running in littleendian mode, %d might produce something interesting if the two halves of the number are switched (as the sign bit will produce something).


Si

[linnuxxy]

I was asking about the output as if the code thought it was running in littleendian mode, %d might produce something interesting if the two halves of the number are switched (as the sign bit will produce something).

The output is just like if u had cat a binary file....long one....

[linnuxxy]

I could getover

I used crosstool 0.38
compile it using

export TARBALLS_DIR=/home/user/crosstool # where it will save source tarballs
export RESULT_TOP=/opt/crosstool # where it will install the tools
export GCC_LANGUAGES="c,c++,java,f77" # which languages it will make compilers for
cd /home/user/crosstool/crosstool-0.38
eval `cat armv5b-softfloat.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --notest

for more info http://kegel.com/crosstool/crosstool-0.38/...tool-howto.html

and it is working now
armv5b-softfloat-linux-gcc hello.c

[lardman]

Coll, glad you got it sorted - I'd be interested to know why you got all that binary stuff out though if you ever find out why.


Si

[linnuxxy]

Coll, glad you got it sorted - I'd be interested to know why you got all that binary stuff out though if you ever find out why.

Thank you, i think it is a bug in the crosstool or something... and the make apply the proper patch to it if i use the above building configureation...although im not sure...