This reverts commit 1c11b857fe.
On windows, libtcc.c is compiled with ONE_SOURCE and then tcc.c is
linked to it. Thus tcc.c can only use public functions which cstr_* are
not.
elements in linker_arg are used in TCCState structure and must thus not
be freed when option parsing is finished. Declare linker_arg as a global
static variable and free it after tcc_delete has been called on TCCState
structure.
This fix commit 7fb0482a46
ld support arguments to multiple-letter options being passed in two
ways:
* -opt=arg
* -opt arg
libtool generate command line of the second form. This commit add
support for the second form so that libtool works with tcc. The way it
is done is to concatenate all -Wl options into one and then pass it to
set_linker.
- use {B} to substitute tcc_lih_path (instead of \b)
- expand CONFIG_TCC_CRTPREFIX in CONFIG_TCC_LIBPATHS
which fixes duplicate CONFIG_SYSROOT.
- put default CONFIG_SYSROOT ("") into tcc.h
- remove hack from commit db6fcce78f
because $(tccdir)/include is already in sysincludes
- configure: error out for unrecognized options.
- win32/build-tcc.bat: put libtcc into base dir where it will
find lib/include automatically, and build libtcc_test example.
This cleans up the mess from commit
8f98573658
and preceeding.
- make tcc -m64 work on windows
- execvp on windows returns 0 always, replace by spawnvp
- remove bizarre support for i386-win32-tcc -m64
This was already possible using
make NOTALLINONE=1
and is now the default.
To build as previously from one big source, use
make ONE_SOURCE=1
Cross compilers are still build from one source because using
separate objects requires separate build directories one per
platform which currently is not (yet) supported by the makefile.
We could probably use gnu-makeish target variables like
$(I386_CROSS): OUTDIR=build/i386
$(X64_CROSS): OUTDIR=build/x86-64
and so on ...
Also NEED_FLOAT_TYPES for arm-gen is removed. It was about
variables that are referenced from outside (libtcc, tccgen).
We could declare them in tcc.h (as with reg_classes) or have
them twice in arm-gen.c. I chose option 2.
The problem was partially fixed by Henry in the following patch:
tcc.c: skip -lpthread when -c option specified
But that patch had one brawback: it is sensitive to argument order,
as decision is taken during commandline parsing:
$ tcc -c a.c -o a.o -pthread # 1. works fine
tcc: error: file 'a.c' not found
$ tcc -pthread -c a.c -o a.o # 2. blows
tcc: error: cannot specify libraries with -c
This patch fixes case 2.
Signed-off-by: Sergei Trofimovich <st@anti-virus.by>
Since for upcoming -MD support default _compile_ output file be needed
even when preprocesssing (tcc -E), let's move this code out of one
particular condition block into a common function, so that we could use
it in deps generation code too.
v2:
- As suggested by grischka, moved into libtcc function instead of always
computing near start of main()
- There is a FIXME about how to return result - I don't want to bother
callers with allocating temp buffers, not I think it will be a good
idea to hook default_target to TCCState. Clearly, I'm to used to
things like std::string and python's str...
files[0], and reloc_outpu will be needed for (upcoming in the next
patch) "compute default outfile name" refactored into libtcc function.
Also, since for symmetry and from libification point of view, it makes
some sense to also put all information about what was given as input to
compilation into TCCState, let's not only put files[0], but all
files and all libraries given explicitely by user.
One point: I've used bitfield for reloc_output & trimmed down
output_type to 8 bits so that TCCState stays the same in size, and also
access to output_type is (hopefully) is not slower.
By the way -- as of today, sizeof(TCCState) on i686-pc-linux-gnu is 2884
bytes...
Without -Bsymbolic, a symbol/function in a *.so can be overridden
by a symbol/function in the main module.
That is the default search order, but not supported by tcc.
With -Bsymbolic, the linker tries to resolve a symbol/function in
the current module first.
The loader in tcc implements this search order.
We do not distinguish -Bsymbolic and -Bsymbolic-function
--
By by ... Detlef
- Cast from pointer to long long makes TCC output an error. Use cast to int before we apply shift operation for a pointer value.
- Removed test cases for casts from pointer to char/short because they produce warning.
- Now we use x87's stack top the long double return values.
- Add rc_fret and reg_fret, wrapper functions for RC_FRET and REG_FRET.
- Add a test case to check if strto* works OK.
- Now we can run tcc -run tcc.c successfully, though there are some bugs.
- Remove jmp_table and got_table and use text_section for got and plt entries.
- Combine buffers in tcc_relocate().
- Use R_X86_64_64 instead of R_X86_64_32 for R_DATA_32 (now the name R_DATA_32 is inappropriate...).
- Add got_table in TCCState. This approach is naive and the distance between executable code and GOT can be longer than 32bit.
- Handle R_X86_64_GOTPCREL properly. We use got_table for TCC_OUTPUT_MEMORY case for now.
- Fix load() and store() so that they access global variables via GOT.
We need malloc and free to implement va_start and va_end.
Since malloc and free may be replaced by #define, we add __builtin_malloc and __builtin_free.
Recently I needed to trim storage space on an embedded distro which has
X.
X depend on cpp which is ~8MB in size as shipped in Debian, so the idea
was to remove cpp and use `tcc -E` instead where appropriate.
I've done this with the following 'hack' put inplace of /usr/bin/cpp :
#!/bin/sh -e
TCC=/home/kirr/local/tcc/bin/tcc
last="${!#}"
# hack to distinguish between '... -D...' and '... file'
if test -r "$last"; then
exec $TCC -E "$@"
else
exec $TCC -E "$@" -
fi
But the problem turned out to be in `tcc -E` inability to preserve
spaces between tokens. So e.g. the following ~/.Xresources
XTerm*VT100*foreground: black
...
got translated to
XTerm * VT100 * foreground : black
which is bad, bacause now X don't understand it.
Below is a newbie "fix" for the problem.
It still does not preserve spaces on macro expansion, but since the fix
cures original problem, I think it is at least one step forward.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
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
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 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
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
