This reverts commit 41fa74fc84.
Reasons for the revert:
1. The commit message is lacking and the use case is not obvious.
At the very least a concrete example of use case should be given
(likely cross-building tcc on platform X for running on platform Y),
followed by an issue description in such use case, and fix descr.
(e.g. "On platform X, when running ./configure ... && make ..., the
build fails because whatever. this commit does Y and fixes it").
2. assign_opt is used incorrectly: 1st arg must be --OPTNAME=VALUE
but it's not. The only thing it does is unconditional host_cc=gcc
if --cross-prefix=... is used - no need for "assign_opt" at all.
3. cross-building tcc currently has several triggers: build/target
cpu differ, or build/target OS differ, or --cross-prefix=... is
used, but that commit only covers the --cross-prefix=... case.
It's possible that it's intentional to only cover one case, but
if so then it's not explained why.
4. The var name host_cc is likely incorrect and probably meant to be
"native_cc", judging by the assigned value "gcc".
5. "gcc" is used unconditionally in such case, without any way to use
a different native compiler (assuming that's indeed the goal).
A better approach is likely supporting --native-cc=... option which
defaults to $cc (which already defaults to "gcc") _before_
$cross_prefix is added in-front.
workflow:
- revert 'pinact for security' for readability
from 831c3fa184
tccpp.c:
- remove code that allows tcc to parse numbers incorrectly (*)
from 829c848520
tccgen.c:
- Revert "Relaxed the 'incompatible pointer type' warning a bit" (*)
from d9ec17d334.
tccrun.c:
- remove support for -nostdlib -run
for simplicity, we require "main" with tcc -run always
tccpp.c:
- Revert "Free all preprocessor memmory in case of error."
from c96f0cad61
Remove TinyAlloc->limit instead. Thus it can do also bigger
allocs. Big TokenStrings (like 200kb+ when compiling tcc)
may come from inline functions or from large initializers.
Makefile/configure:
- use --config-pie for configuring tcc output only
- use -fPIC with clang-x86_64 to avoid 32-bit relocs
libtcc.c:
- fix "tcc file.c -run" i.e. -run as last argument
i386-gen.c:
- PIC refactor
(*) sorry, but code in tcc should have a minimum of generic relevance
I tried several gdb/lldb options to debug libtcc generated code.
But gdb/lldb complained that they could not load symbols or
that module does not exist. There was also another problem. The
code itself was in memory (string) and gdb/lldb do not have
functions to acces it.
So I came up with a new api for debugging libtcc code.
First you enable debugging with: tcc_set_options(s, "-g")
Then compile the code with: tcc_compile_string_file(s, program, "<file>.c")
Then call tcc_relocate().
And finaly write the object file to disk: elf_output_obj(s, "<file>.o")
Now you can start the debugger and put an breakpoint after the
elf_output_obj() code. Then use gdb command add-symbol-file <file>.o
and from there on you can set breakpoints in the libtcc generated code.
You can also step/print variables/...
I could not find a simular function in lldb yet.
When debugging is done you remove the tcc_set_options(s, "-g").
All other code can remain because tcc_compile_string_file and
elf_output_obj do not output any file any more is debug is not set.
See also tests/libtcc_debug.c
Some targets (netbsd) require that code is
compiled with -fPIE.
i386-gen.c:
Lot of changes to load/store code
i386-link.c:
Set PCRELATIVE_DLLPLT depending on configuration
tccelf.c:
Change some relocations and add get_pc_thunk.o
Makefile lib/Makefile lib/get_pc_thunk.S:
Add new file get_pc_thunk.o
According to AAPCS64, when an argument requires 16-byte alignment
and is passed on the stack, the stack address must be rounded up
to the next 16-byte boundary.
TCC previously failed to perform this alignment check in gen_va_arg,
leading to data corruption when a 16-byte aligned argument followed
an 8-byte argument on the stack.
Note: This issue is most prominent on Mach-O/Apple Silicon where
variadic arguments are passed entirely on the stack. Testing shows
this fix resolves the failure on macOS while remaining compatible
with Linux/ARM64 (e.g., Raspberry Pi).
Modified gen_va_arg to perform a round-up (addr + 15) & ~15 when
align == 16.
When accessing a global symbol with an addend > 0xffffff, the AArch64
backend incorrectly encoded an 'add xr, xt, #0' (Add Immediate)
instead of 'add xr, xr, xt' (Add Register).
This resulted in the base address of the symbol being overwritten
by the offset value rather than being summed with it.
Fixes the issue where (sym + 0x1000000) would resolve to 0x1000000
instead of the correct memory address.
When calculating the difference between two pointers (TOK_PDIV), the
AArch64 and RISC-V64 backends used unsigned division
instructions (udiv/divu).
This patch moves TOK_PDIV to use signed division instructions (sdiv/div)
for both backends, ensuring correct behavior as per the C standard.
x86_64-link.c:
Check relocations R_X86_64_32/R_X86_64_32S. These relocations
can become to large if not configured with '--disable-static'
or '--config-pie' and code is run with -run -ltcc.
This only happens on x86_64.
tccdbg.c:
1) Add some .debug (dummy) sections when dwarf is used. These
sections are otherwise not relocated correctly for R_DATA_32DW.
2) Fix stab problem when reloc is applied twice.
I found some problems with a testcase from mailing list.
On x86_64 an overflow on reloc R_X86_64_32 occurred that was
not reported when using -run -ltcc.
The problem could be solved by compiling tcc with -fPIE, -pie
or --disable-static.
Makefile, configure, libtcc.c, x86_64-link.c:
- add --config-pie to configure help. Ignore -pie in libtcc.c
and check reloc overflow in x86_64-link.c
arm64-gen.c:
- Fix reading from constant like '*(int *)0x7fffb7f1280c'
elf.h, riscv64-link.c:
- fix for -run -ltcc. Ignore reloc R_RISCV_SET_ULEB128 and
R_RISCV_SUB_ULEB128 that are used in .debug_loclists section.
Add the define TCC_CUT_ON_INTEGER_LITERAL_OVERFLOW to use the most
significant digits of an integer literal before its parsing led to an
overflow.
When compiling tcc with another compiler, which is not able to handle
64 bit arithmetic, it is beneficial to use the last value before an
integer literal overflows. Parsing 0x1000000000000000 then results in
0x10000000. The mescc from GNU Mes is able to compile a first tcc on a
32 bit system without 64 bit arithmetic. This change allows this first
tcc to compile a second tcc with complete 64 bit arithmetic.
Placing the definition of "pure" prior to TOK_DEFINE would cause it to
be treated as a keyword by tccgen. This breaks building gcc, in which
"pure" is used as a struct field name.
The -run option did not support -nostdlib correctly.
The argc/argc/envp are now passed on stack according to sysv.
This implementation does not work for TCC_TARGET_PE.
Also arm64 does not work when running tcc compiled with itself.
This is because arm64 assembly is not implemented yet.
The following test code is used to check the code:
#include <unistd.h>
#include <sys/syscall.h>
void _start() {
syscall(SYS_write, 1, "hello world\n", 12);
syscall(SYS_exit, 0);
}
Run this with:
./tcc -nostdlib -lc -run a.c
make tcc_c
./tcc_c -nostdlib -lc -run a.c
Do not emit that warning when the source struct (recursively) contains destination struct as the first member. For example, in this case the warning would have been emitted before, and is not anymore:
struct base {
int a;
};
struct derived {
struct base base;
int b;
};
struct derived derived;
struct base *base = &derived;
I personally use that pattern in my code (in a bit more elaborate form) and so this change removes the warnings for those use cases, while still retaining it for everything else. Feel free to CC me on the mailing list if you have questions, suggestions or complaints.
When tcc -run is used with input file from stdin, then run_main's
stdin (which is tcc's stdin) is already EOF after we've read it.
If the program operates exclusively on stdin, then it cannot be used.
This commit adds an option -rstdin FILE which sets run_main's stdin.
Can also be used in such case to set run_main's stdin to the tty,
using -rstdin /dev/tty (posix) or -rstdin con (windows).
The tcc options behavior is non trivial, and it's also susceptible
to ambiguities - which do exist (but currently are not painful).
- Add a script 'optclash' which detects clashes/ambiguities.
- Document the parsing behaviour and current clashes/resolutions
as comments in libtcc.c .
tcc.h, tccgen.c:
Add and use IS_BT_ARRAY
tccpp.c:
free memory when size is 0 in realloc code
tccdbg.c:
move common code to seperate function remove_type_info
- include/stddef.h, tcctest.c
Revert "tests/tcctest.c: include stdint.h"
This reverts commit 8f23997ca7
We don't want tcctest.c to rely on system include files
- libtcc.c:
Revert "libtcc.c: Remove unused defines free and realloc"
To be unused is the point why they do exist
This reverts commit 2f88764100.
- tcc.c:
fix formatting of commit e73529865d
- tccpp.c:
parse_include(): print skipped include files too (with tcc -vv[v] file)
next_nomacro(): faster L"str" parsing
- tccgen.c: fix c2y if declaration:
* accept like GCC: if (int a = 0, b, c = x; c)
* accept as "TCC extension": if (int a = 0, b, c = x)
* "speak tcc" with symbol/function names
- README:
cleanup
