The fallback CONTEXT struct for ARM64 (used when __aarch64__ is defined
but _ARM64_CONTEXT_DECLARED is not set) incorrectly defined V[32] as
DWORD64 (64-bit) instead of ARM64_NT_NEON128 (128-bit).
This caused register corruption when RtlRestoreContext restores NEON/VFP
registers, as the struct size was 256 bytes instead of the correct
512 bytes.
Fixes potential corruption on toolchains that define __aarch64__ but not
_ARM64_ (e.g., clang on macOS or certain cross-compilation scenarios).
Improve the warning about an integer constant overflow with the used
overflown value and the potentially aimed value.
This helps spotting the 0 to much in 0x80000000000000000.
Track R_RISCV_PCREL_HI20/GOT_HI20 relocations by address and resolve LO12 relocations against the referenced HI, instead of only using the last seen HI.
Also reset/free the per-link relocation map in TCCState.
Moving the u128_t struct may invoke calls to memcpy/memmove when
compiled with tinycc, which would depend on libc.
For example, some configure scripts get confused if they fail to build
test programs involving long doubles. I'm not sure if this is the root
cause, though.
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.
