This reverts commit 3f8225509b.
It fixes the linking case but introduces an ugly error with -c
about adding a library. To fix both uses the old code structure is
better.
adding -pthread confused option parsing as the number of file counting
came out wrong. Simplify and fit it, can be handled purely within
option parsing, no need for a state flag.
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
This is supposed to make compilation and linking with
multiple source files (tcc f1.c f2.S ...) behave just
the same as linking object files.
tccgen.c:put_extern_sym2():
- use put_elf_sym to enter new symbols unconditionally
tccelf.c:
- save section state before compilation
- disable symbol hashing during compilation
- merge symbols and update relocations after compilation
tccpe.c:
- re-create s1->uw_sym for each compilation (because it
may change)
for this we have to create also asm symbols as VT_STATIC initially
except if there's an indication that it should be global (.globl
or undefined at end of unit). For this to work we need to
be able to globalize symbols after they were local and enter them
into the ELF hash tables, and also adjust the symbols that were
potentially already used in relocs when they were still local.
The easiest is to do a proper symbol resolution step also in multi-file
mode, for regular symbols (the non-dynamic ones, i.e. not from shared
libs).
tccgen.c:
- improved function patch_storage() and added new function
patch_type() for more consistent type redefinition and
instance redefinition checks.
* removed asm_label stack
* removed asm_free_labels() post-processing
* using "impossible C type" for asm labels (VT_ASM)
* tccgen.c:update_storage(): use it to refresh symbol attributes
* tccelf.c:find_elf_sym(): ignore STB_LOCAL symbols
* tccgen.c:unary(): asm symbols are supposed to be undeclared in C
See testcase (from grischka). If the asm has no .globl,
but there's a (non-static) C definition the symbol should
be exported, even if the first reference comes from asm.
The length suffix for cmovCC isn't necessary as the required register
operands always allow length deduction. But let's be nice to users
and accept them anyway. Do that without blowing up tables, which means
we don't detect invalid suffixes for the given operands, but so be it.
This makes the asm symbols use the same members as the C symbols
for global decls, e.g. using the ELF symbol to hold offset and
section. That allows us to use only one symbol table for C and
asm symbols and to get rid of hacks to synch between them.
We still need some special handling for symbols that come purely
from asm sources.
For tracking if asm symbols are connected with a C symbol,
and if asm symbols need to be global use new flags, instead of
reusing dllimport/dllexport, which would cause unrequested exported
entries on Windows.
This is a stop-gap until the C and asm symtable are unified.
See testcase. The C and asm symtab are still separate,
but integrated tighter: the asm labels are only synched at file
end, not after each asm snippet (this fixes references from one
to another asm block), the C and asm syms are synched both ways,
so defining things in asm and refering from C, or the other way
around works. In effect this model reflects what happens with
GCC better.
For this the asm labels aren't using the C label namespace anymore,
but their own, which increases the size of each TokenSym by a pointer.
one some systems GCC defaults to PIC/PIE code which is incompatible
with a unannotated asm call to a function (getenv here). TCC doesn't
support these PIC annotations (yet), so play some pre-processor games.
while last change fixed one part of label behaviour (undefined ones
must be global) it again broke a different aspect (forward defs
without .globl must stay local). This fixes both aspects.
That a label is local instead of global is difficult to test without
resorting to look at the symbol table or using two-file testcases,
so we do without. In essence the local/global-ness of symbols
should be the same between GAS and TCC for this input:
.globl glob1
glob1:
call glob1
.globl glob2
call glob2
glob2:
glob3:
.globl glob3
call glob3
glob4:
call glob4
.globl glob4
call glob5
.globl glob5
glob5:
call glob6
glob6:
.globl glob6
locl1:
call locl1
call locl2
locl2:
unref1:
unref2:
.globl unref2
.globl unref3
unref3:
call undef
fixes the problem in the testcase. A symbolic reference
from asm, which remains undefined at the end of processing is
always a global reference, not a static (STB_LOCAL) one.
This also affected the linux kernel.
This properly fixes what 870271ea tried to fix. Absolute memory
references can't use %rip relative addressing, and additionally,
if the address doesn't fit 32bit (signed) it must be loaded via
movabs. No good testcase added, it would require catching signals
and still be unreliable.
This reverts commit 870271ea07.
The commit is broken, you can't unconditionally emit a PC-relative
relocation without a symbol. And if there's a symbol the addend
need to be in the relocation, not the section.
win32/Makefile ("for cygwin") removed
- On cygwin, the normal ./configure && make can be used with either
cygwin's "GCC for Win32 Toolchain"
./configure --cross-prefix=i686-w64-mingw32-
or with an existing tcc:
./configure --cc=<old-tccdir>/tcc.exe
tcctest.c:
- exclude test_high_clobbers() on _WIN64 (does not work)
tests2/95_bitfield.c:
- use 'signed char' for ARM (where default 'char' is unsigned)
tests:
- remove -I "expr" diff option to allow tests with
busybox-diff.
libtcc.c, tcc.c:
- removed -iwithprefix option. It is supposed to be
combined with -iprefix which we don't have either.
tccgen.c:
- fix assignments and return of 'void', as in
void f() {
void *p, *q;
*p = *q:
return *p;
}
This appears to be allowed but should do nothing.
tcc.h, libtcc.c, tccpp.c:
- Revert "Introduce VIP sysinclude paths which are always searched first"
This reverts commit 1d5e386b0a.
The patch was giving tcc's system includes priority over -I which
is not how it should be.
tccelf.c:
- add DT_TEXTREL tag only if text relocations are actually
used (which is likely not the case on x86_64)
- prepare_dynamic_rel(): avoid relocation of unresolved
(weak) symbols
tccrun.c:
- for HAVE_SELINUX, use two mappings to the same (real) file.
(it was so once except the RX mapping wasn't used at all).
tccpe.c:
- fix relocation constant used for x86_64 (by Andrei E. Warentin)
- #ifndef _WIN32 do "chmod 755 ..." to get runnable exes on cygwin.
tccasm.c:
- keep forward asm labels static, otherwise they will endup
in dynsym eventually.
configure, Makefile:
- mingw32: respect ./configure options --bindir --docdir --libdir
- allow overriding tcc when building libtcc1.a and libtcc.def with
make XTCC=<tcc program to use>
- use $(wildcard ...) for install to allow installing just
a cross compiler for example
make cross-arm
make install
- use name <target>-libtcc1.a
build-tcc.bat:
- add options: -clean, -b bindir
Currently tcc doesn't have a compile-time config indicating that the target
is freebsd, and as a result, the tcc binary adds freebsh stuff to elf headers
if the compile-time (of tcc) *host* is freebsd.
Test also that the target is not PE while generating an elf header.
This still likely fails (but untested) when tcc targets other non-freebsd
systems on a freebsd system, but for now fix it only when targetting windows.
add some features for more complete 'long' support
tcc.h:
- use LONG_SIZE=4/8 instead of TCC_LONG_ARE_64_BIT
tccgen.c:
- add ptrdiff_type, update size_type
- support shift and ?: operations
- support long enum types
- display 'long' from type_to_str
- nwchar_t is unsigned short on windows
- unrelated: use memcpy in init_putv for long doubles to avoid
random bytes in the image (if tcc was compiled by gcc) for
diff purposes.
tccpp.c:
- make parse_number return correct types
- improve multi-character-constants 'XX' 'abcd'
Changelog:
- update
Dereferencing of absolute pointers is broken on x86_64, eg:
*(int*)NULL does not segfault but returns -4 instead
*(char*)(-10L << 20) does not return 0x55 (vsyscall page, push rbp)
The code generated for "((void (*)(void))0x12345678)()" will be a single "CALL 0x12345678" in previous code.
However, this will not work for DLLs, because "CALL imm" is PC related, DLL relocation will break the code.
This commit fixed the problem by forcing TCC generates indirect CALLs in this situation.
AL/AX should be extended to EAX when calling functions. However, the previous code did this only for direct calls, indirect calls were ignored.
New code also avoid redundant code when generating JMP instruction. (i.e. expanding code should be generated with CALL instruction only)
This commit fixed the problem that TCC directly cast each byte in wide string literal to wchar_t, which is wrong when wide string literal contains real wide chars.
It fixed the problem by assuming input charset is UTF-8, and wchar_t stores wide chars in UTF-16 (Windows) or UTF-32 (others).
The UTF-8 decoder is coded according to The Unicode Standard Version 10.
Too simple long parsion.
Take me a long long long time to see my mistake,
Sorry
(long long long wasn't see as an error)
This reverts commit a4cd2805f9.
