This allows creation of TCCStates and operation with API
calls independently from each other, even from threads.
Frontend (option parsing/libtcc.c) and backend (linker/tccelf.c)
now depend only on the TCCState (s1) argument.
Compilation per se (tccpp.c, tccgen.c) is still using
globals for convenience. There is only one entry point
to this section which is tcc_compile() which is protected
by a semaphore.
There are some hacks involved to avoid too many changes,
as well as some changes in order to avoid too many hacks ;)
The test libtcc_test_mt.c shows the feature. Except this
new file the patch adds 87 lines overall.
tccgen.c:
- fix ldouble asm hack
- fix a VLA problem on Win64 (also x86_64-gen.c)
- patch_type(): make sure that no symbol ever changes
from global to static
tcc.c:
- tcc -vv: print libtcc1.a path also on win32
tccpe.c, tcctools.c:
- use unix LF mode to for .def output files (that is for
creating reproducible output trees)
Makefile:
- suppress some warnings when makeinfo is missing
- call 'which install' only on win32
tests/Makefile:
- change PATH only on WINNT systems (i.e. not if cross-compiling
on linux for win32)
- asm-c-connect.test: slim output and do diff
tccrun.c tccpe.c *-link.c:
- integrate former 'pe_relocate_rva()' into normal relocation
This also fixes linkage of the unwind data on WIN64 for -run
(reported by Janus Lynggaard Thorborg)
tccasm.c, tests/tcctest.c:
- fix dot (sym_index of -1 crashed in put_elf_reloc)
- massage .set a bit (see test)
other:
- #define SECTION_ABS removed
- ST_DATA Section *strtab_section: removed
- put_extern_sym2(): take int section number
Conflicts:
tccelf.c
tccpe.c
Conflicts:
tccelf.c
since configure supports only native configuration
a file 'cross-tcc.mak' needs to be created manually.
It is included in the Makefile if present.
# ----------------------------------------------------
# Example config-cross.mak:
#
# windows -> i386-linux cross-compiler
# (it expects the linux files in <prefix>/i386-linux)
ROOT-i386 = {B}/i386-linux
CRT-i386 = $(ROOT-i386)/usr/lib
LIB-i386 = $(ROOT-i386)/lib:$(ROOT-i386)/usr/lib
INC-i386 = {B}/lib/include:$(ROOT-i386)/usr/include
DEF-i386 += -D__linux__
# ----------------------------------------------------
Also:
- use libtcc1-<target>.a instead of directories
- add dummy arm assembler
- remove include dependencies from armeabi.c/lib-arm64.c
- tccelf/ld_add_file: add SYSROOT (when defined) to absolute
filenames coming from ld-scripts
* Documentation is now in "docs".
* Source code is now in "src".
* Misc. fixes here and there so that everything still works.
I think I got everything in this commit, but I only tested this
on Linux (Make) and Windows (CMake), so I might've messed
something up on other platforms...
abitest now passes; however test1-3 fail in init_test. All other tests
pass. I need to re-test Win32 and Linux-x86.
I've added a dummy implementation of gfunc_sret to c67-gen.c so it
should now compile, and I think it should behave as before I created
gfunc_sret.
Just like with test[123] add their test[123]b variants. After previous 3
patchs all test pass here on Debian GNU/Linux on i385 with gcc-4.7 with
or without memory randomization turned on.
The following files were not ignored (produced by build on i386 with
--enable-cross):
arm-eabi-tcc
arm-fpa-ld-tcc
arm-fpa-tcc
arm-vfp-tcc
c67-tcc
i386-win32-tcc
lib/i386-win32/
lib/x86_64-win32/
x86_64-tcc
x86_64-win32-tcc
When using gcc compiler (as opposed to llvm) to build 32 bit tcc, compiler flags
-mpreferred-stack-boundary=2, -march=i386 and -falign-functions=2 were being
used. -march is redundant as -m32 is already being used. The other two seem to
be corrupting stack. I am not sure why this is the case, as the explanation of
the flags states that only running code size should be affected, but it does.
I think that is is safe to remove these flags altogether for all compilers and
platforms, especially since they are not being used for 64 bit builds. However
I do not want to apply such wide change without agreement from the people on the
mailing list.
Other tests still have issues, currently with weak linking.
One of the primary stumbling blocks on OSX is the lack of support for
mach-o binaries. Therefore all tcc usage on OSX has to be limited to elf
binaries, presumably produced by tcc itself.
Therefore I had to enable building of tiny_libmaker for OSX. Then changed
the make to use tcc and tiny_libmaker to compile the tcclib1.
In order to compile the tests, specifically the parts that use weak linking,
I have had to define MACOSX_DEPLOYMENT_TARGET to 10.2, which seems like a
hack, but extensive searching seems to indicate that this is the only way
to make apple gcc allow weak linking. Using any other value, bigger or smaller
breaks weak linking.
Also added _ANSI_SOURCE define required by some OSX headers, and some cosmetic
gitignore changes. I believe these changes should not impact other platforms.
Applied patch found on stackoverflow (link below). I also found some
related changes that looked like logically needed. The stackoverflow
changes addressed only two registers which were breaking a compile.
However reading the code in the same file shows two other register
accesses that, while not breaking the build, should have the same fix.
http://stackoverflow.com/questions/3712902/problems-compiling-tcc-on-os-x/3713144#3713144
The test driver was changed by changing 'cp -u' into 'cp' as '-u' is not
supported on mac osx.
I found that osx build required the WITHOUT_LIBTCC define. I suspect the
reason for this is tcc unability to handle mach-o files. In order to
properly address this I had to change 'configure' to propagate target os
name to Makefile.
Current state is that simple tests work, but not the whole 'make test'
suite runs.
To the best of my knowledge, these changes should not impact other
platforms.
We no longer use CVS, so let's teach Git about what files to ignore...
... though doing `git status` after make + `make test` still gives
untracked content:
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# alloca86-bt.o
# alloca86.o
# bcheck.o
# libtcc.a
# libtcc.o
# libtcc1.a
# libtcc1.o
# tcc.o
See next patch about this stuff.
