[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] TCC on new ARM EABI (ARMEL)

From: Cayle Graumann
Subject: Re: [Tinycc-devel] TCC on new ARM EABI (ARMEL)
Date: Thu, 7 Sep 2006 23:10:08 -0500


     I tried this suggestion, but I still get segmentation faults when I try to recompile TCC using the ARM-TCC.

     However, I did have some small success under the scratchbox ARM under QEMU cross compilation environment.

     These are the steps I did:

     1) I used the head version out of the new Subversion (revision 12)
     2) I used Daniel's patched libtcc1.c.
     3) I configured with --enable-cross and compiled TCC in the i386 environment, that was successful.  The configuration step is necessary later, since the config.h file is  not generated under the ARMEL (EABI) environment when configure is run.  The compilation was just a further test to see if everything was OK. 
     4) make install for later testing.  Followed by a make clean to remove any compiled code in the tcc directory.
     5) I switched to the ARMEL (EABI) environment, and reconfigured with --enable-cross.  As mentioned before the config.h file was not made.  Don't know why, but I've seen it happen before in scratchbox.
     6) I edited the makefile to remove the -m386 parameters, since no longer on i386.  Also removed the -falign-functions=0 parameter (this may be necessary)
     7)  I compiled TCC. 

           There are numerous warnings about breaking strict-aliasing. 

           There is one error in bcheck.c.  I took a cue from the FreeBSD folks and forceable undefined the CONFIG_TCC_MALLOC_HOOKS and HAVE_MEMALIGN.  I commented out the compiler error message to extracting the calling frame pointer.   This results in a warning about an implicit declaration of GET_CALLER_FP.

           There is one error in tcc.c where it indicates that the rt_get_caller_pc function needs to be implemented.  Looking at this code, I think this might well be very similar to the code that is already present for i386 at least under Linux, since the mcontext struct contains the gregs entry. I don't know if the address validity numbers (on i386 the addresses are deemed valid if they are between 0x1000 and 0xc0000000) will be the same.  I don't know enough about ARM hardware to know for sure.

      8) Everything compiles after these modifications.  The arm-tcc will still not compile itself.

      9)  I have a test C file that will compile if I use arm-tcc -c to produce an object file.  It will not link and produce an executable file.  Trying to link the resulting .o file with arm-gcc results in the following error message (Data is the name of the file I'm working with)

                           ERROR: Source object Data.o has EABI version 0, but target Data has EABI version 4

Conclusions:  tcc can compile under arm-gcc, but it creates object files that cannot be linked with existing libraries because the object format has changed.  This might explain why the arm-tcc seg faults under i386 when it tries to link to the ARMEL crt*.o files and to the ARMEL libc.   I do not know what the byte order is when I compile it this way.

I don't really know enough about ARM to be much more help.  And I don't know anything about the EABI changes, although if I can find a spec, I might be able to do something more.

On 9/7/06, Ivo <address@hidden> wrote:
On Thursday 07 September 2006 23:29, Cayle Graumann wrote:
> Daniel,
>     So let me get this straight:
> 1) I compile TCC as an arm cross compiler.
> 2) I use i386-TCC to re-compile TCC as arm cross compiler

Not sure what you exactly mean, but I think he means:

on i386:        compile tcc as an arm cross-compiler that runs on i386 and
                generates arm code

on i386:        with that cross-compiler, compile an arm native compiler ( i.e.
                one that runs on arm and generates arm code)

on arm: with that arm native compiler, compile another arm native compiler

The last compiler....

> The arm-TCC should then produce working executables?

...should produce correct binaries, according to Daniel Glöckner.


Tinycc-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]