|Subject:||Re: [Tinycc-devel] TCC on new ARM EABI (ARMEL)|
|Date:||Fri, 8 Sep 2006 09:04:19 -0500|
On Thu, Sep 07, 2006 at 11:10:08PM -0500, Cayle Graumann wrote:
> 5) I switched to the ARMEL (EABI) environment, and reconfigured with
> --enable-cross. As mentioned before the config.h file was not made.
Probably because uname -m is armv5tejl and configure only knows about
> There is one error in bcheck.c.
Bounds checking is not implemented for ARM and the Makefile does not
link bcheck.o into arm-tcc.
> 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
The problem is that on ARM the address of the caller is not passed on
the stack, but in register LR and the ABI does AFAIK not say where to
save that register in the stack frame. If we write a rt_get_caller_pc,
it will work for all functions compiled by tcc, but if the caller has
been compiled by another compiler, it may fail. There is no way for
rt_get_caller_pc to distinguish compilers. As rt_get_caller_pc is only
used to make error messages more verbose, there is no real need to
> 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.
Any error message?
Glibc on gnueabi targets uses ld-linux.so.3 instead of ld-linux.so.2 as elf
interpreter. Change in tccelf.c .
> ERROR: Source object Data.o has EABI version 0,
> but target Data has EABI version 4
Set ehdr.e_flags to X<<24 for EABI version X in tcc_output_file().
The ABI says ehdr.e_ident[EI_OSABI] should be set to 0 and not to
ELFOSABI_ARM (=97). If someday tcc uses symbol versioning, it should be
set to ELFOSABI_ARM_AEABI (=64).
On the ARM website I can only find the spec for the current EABI version 5.
> 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.
L says little-endian.
> 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.
I skipped through the spec and noticed these differences:
- VFP instead of FPA floatingpoint coprocessor (different instructions)
- Stack needs to be aligned on an 8 byte boundary on function entry
- 8 byte values (and structs containing those) need to be aligned on an
8 byte boundary
- sizeof enums depends on the values in the enum
- R_ARM_PC24 is marked as deprecated (but should still work). There are
new relocation types.
Other things that need to be changed:
- TinyCC does not know how to call Thumb functions
- found a bug: when return type is a struct with sizeof()<=4, it must
be returned in register R0
Tinycc-devel mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|