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
- Use REL_SECTION_FMT instead of ".rel%s".
- Use PTR_SIZE instead of sizeof(int) for GOT entries.
- Use sizeof(ElfW(Dyn)) instead of magic number 8.
- Use TCC_ELFCLASS instead of ELFCLASS32.
Adding the GCC extension __builtin_frame_address(). We support only zero as the argument for now.
With this functionality, we can implement GCC compatible stdarg by macros in x86-64.
nocode_wanted can't be used to enforce constant expressions, as it is
set f.ex. by __builtin_constant_p.
A null pointer is unequal to a pointer to any object or function.
Assuming symbols always point to memory, a symbol+constant cast to bool
is always true.
Casting of constants was done only inside functions.
I restructured the code and used intermediate types (long double/long long)
for most conversions to have less ifs.
Please review.
There are lots of cases to take care of and lots of mistakes to make.
The return type of a statement expression (a GCC extention) may
involve elements on the symbol stack that have been put there by
the expression. These will be freed at the end of the expression
so that the calling block can not use them.
Contrary to the comment (written in 2003), this bug no longer shows
up in Valgrind, as freed symbols are now put onto a stack for later
reuse.
The ISO C draft allow only signed/unsigned int and _Bool as base type
for bitfields. TinyCC ever since allowed a wider range of types, but
there were many bugs that shifted values when they shouldn't, etc..
The patch introduces a restriction to the layout of bitfields with
mixed types that makes it incompatible with GCC. In
struct {
typeA x:1;
typeB y:1;
};
y is combined with x in the same byte iff typeA is typeB (neglecting
signedness). This is done to avoid alignment issues and exceeding the
width of typeA.
TinyCC sometimes has problems to evaluate constant expressions at
compile time. This leads to code being generated outside of functions.
Without this patch some of these bugs are not caught, because
cur_text_section still points to the section of the last function.
Before the first function cur_text_section is uninitialized.
Setting cur_text_section to a null pointer should make TinyCC die in
all cases.
long long a();
long long b() {
return a();
}
At the end of b there will be some useless register shuffling.
This is because return wants to have the result of a in REG_IRET.
gv checks if this is the case for BOTH registers of the long long.
After this test it uses REG_LRET for the second register if the
first is supposed to be REG_IRET. In other cases it uses RC_INT.
The patch compares the second register against the class it will
have in the end instead of the register class the first register
will have.
At this point I would like to remind those who pick up the patches
that there are two other mails by me with uncommitted fixes:
http://lists.gnu.org/archive/html/tinycc-devel/2003-10/msg00044.htmlhttp://lists.gnu.org/archive/html/tinycc-devel/2008-08/msg00007.html
Daniel
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
- Builds all four possible ARM targets when cross compiling
- Adds some auto detection to select the target for native ARM builds
The auto detection will select EABI if it finds /lib/ld-linux.so.3.
It will select VFP floating point support when /proc/cpuinfo lists
a VFP or iWMMXt coprocessor. Intel Wireless MMX does not imply VFP,
but it conflicts with FPA, so VFP is the only choice (apart from
yet unsupported soft-float).
Daniel
Yesterday I felt the urge to change a few things in TinyCC.
This is the first and biggest change of all of them.
- use __aeabi_*divmod functions in ARM EABI to make binaries depend
solely on standardized library functions
- refactor ARM floating point <-> integer conversion a bit
- rename long long->float and shift library functions to correspond to
the names used by GCC
- compile more tokens conditionally to reduce the size of TinyCC
The intention is primarily to allow users of the ARM target to use
libgcc (which is usually available as a shared library) instead of
libtcc1 (which can't be compiled for ARM due to lack of an inline
assembler).
Changing the EABI target to use the divmod functions in theory allows
to use it without libtcc1 on any (not necessarily GCC based) ARM EABI
system.
Daniel
