crosstool-0.28-rc7, host cygwin, target ARM

[Dan Kegel]

Michael Röhner wrote:
> Very little, ugly "test program":
> 
>   #include <stdio.h>
>   #include <float.h>
> 
>   int main(void)
>     {
>       float f1,f2;
> 
>       puts("Test");
> 
>       f1 = 12.3;
>       f2 = 45.6;
>       printf("%f\n",f1 / f2 * 10.0);
> 
>       return (0);
>     }
> 
> Compiled with
>   CFLAGS = -Wall -O2 -march=armv4 -mtune=strongarm1100
> and
>   CFLAGS = -Wall -static -O2 -march=armv4 -mtune=strongarm1100
> 
> 
> Results:
> 
>                 toolchain  -static                 dynamic link
> gcc     libc    compile    test program            test program
> 
> 2.95.3  2.1.3   +          +                       +
> 3.3.2   2.3.2   +          2 illegal instruction   [ 1 float output error ]
> 3.3.3   2.1.3   3 error    -                       -
> 3.3.3   2.3.2   +          2 illegal instruction   [ 1 float output error ]
> 3.4.0   2.3.2   +          +                       [ 1 runtime link error ]
> 3.4.0   2.1.3   4 error    -                       -

(What do + and - mean?  + means worked, and - means didn't try?)

The float output error is probably fixed by crosstool-0.28-rc*/contrib/glibc-vfp.patch
Try copying that into patches/glibc-2.3.2 and see if that helps... but come to think
of it, maybe it won't, since you are running against 2.1.3.  Hrmph.

> (1) Ok, since tested on a system with only libc 2.1.3 .so installed
>     (not enough disk space to install new libc).

> (2) It seems to me that there is an error in libc. Maybe false target
>     or maybe compiled for xscale instruction set, but has to run on
>     StrongARM which does not have  some (dsp like) instructions
>     implemented or ... ? - Or missed I something and xscale compiling
>     is default (instruction set > armv4) for some newer compilers?

Yes, maybe you need to set a cpu option; you can set -mcpu=xxxx in TARGET_CFLAGS,
and --with-cpu=xxxx and  --enable-cxx-flags=-mcpu=xxxx in GCC_EXTRA_CONFIG,
like ppc405.dat does, maybe.

> Another question: For example, is it possible to compile with
> gcc 3.3.3 and libc 2.1.3 toolchain (assuming (3) is solved),
> and run against gcc 2.95.3 compiled libc 2.1.3 .so ?

Yes.  There might be some problem if the app needs libgcc.so, but
that's probably just exception handling, so if you're doing plain C
apps, you're probably fine.  I just did this today, a couple test
apps ran fine (on x86).  Didn't try anything that needed libgcc.so.


There have been some good posts on http://lists.arm.linux.org.uk/pipermail/linux-arm/
lately, be sure to ask there too.

> Reading the list I see that there are newer unofficial? releases of crosstool.
> Regarding http://www.kegel.com/crosstool/ rc7 is newest.
> But I found http://www.kegel.com/crosstool/crosstool-0.28-rc12.tar.gz.
> 
> Does it make sense to do my tests with this version?
> Do you know a URL or mailing list where the release candidates were announced?
> I took a 0.28-rc instead 0.27 for better cygwin support.

crosstool-0.28-rc12 has only small improvements over rc7; I was trying out lots
of little things for sparc64 etc.  Either it or rc7 is fine.
The release candidates are announced to crossgcc@sources.redhat.com when they're worth mentioning.

> In the crosstool directory are gcc*dat files for possible combinations with
> libc. And there is a demo-arm.sh, inside not so much combinations. So, is it
> useless to try other combinations as in demo-arm.sh? 

Wie bitte?  :-)

The demo-arm*.sh files were really quickly thrown together,
I'm sure they could be improved.

Do you know if you want soft-float, by the way?

MfG

Dan Kegel

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com