Most change was done in #ifdef TCC_TARGET_X86_64. So, nothing should be broken by this change.
Summary of current status of x86-64 support:
- produces x86-64 object files and executables.
- the x86-64 code generator is based on x86's.
-- for long long integers, we use 64bit registers instead of tcc's generic implementation.
-- for float or double, we use SSE. SSE registers are not utilized well (we only use xmm0 and xmm1).
-- for long double, we use x87 FPU.
- passes make test.
- passes ./libtcc_test.
- can compile tcc.c. The compiled tcc can compile tcc.c, too. (there should be some bugs since the binary size of tcc2 and tcc3 is differ where tcc tcc.c -o tcc2 and tcc2 tcc.c -o tcc3)
- can compile links browser. It seems working.
- not tested well. I tested this work only on my linux box with few programs.
- calling convention of long-double-integer or struct is not exactly the same as GCC's x86-64 ABI.
- implementation of tcc -run is naive (tcc -run tcctest.c works, but tcc -run tcc.c doesn't work). Relocating 64bit addresses seems to be not as simple as 32bit environments.
- shared object support isn't unimplemented
- no bounds checker support
- some builtin functions such as __divdi3 aren't supported
This patch adds a switch --with-libgcc to configure.
When passed it prevents libtcc1.a from being built and links to
/lib/libgcc_s.so.1 instead of PREFIX/lib/tcc/libtcc1.a.
It will work on ARM when using libgcc from GCC >= 4.2.0.
Prior versions don't have the __floatun[sd]i[sdx]f functions.
It won't work on i386 because of two missing symbols emitted when
floats are cast to integers, but users can provide those symbols
(global short constants) in their code if needed.
Daniel
This patch is useful for cross compilers. Without this patch tcc
tries to use the host's libraries, crt*.o and include files.
The patch prepends a string to all default paths. The string can
be passed to configure with --sysroot=string.
Daniel
