Two things: negative constants were rejected (e.g. "add $-15,%eax").
Second the insn order was such that the arithmetic IM8S forms
weren't used (always the IM32 ones). Switching them prefers those
but requires a fix for size calculation in case the opcodes were
OPC_ARITH and OPC_WLX (whose size starts with 1, not zero).
The check for structs was too late and on amd64 and aarch64 could
lead to accepting and then asserting with code like:
struct S {...} s;
char *c = (char*)0x10 - s;
Fix it to actually be able to parse 64bit immediates (enlarge
operand value type). Then, generally there's no need for accepting
IM64 anywhere, except in the 0xba+r mov opcodes, so OP_IM is
unnecessary, as is OPT_IMNO64. Improve the generated code a bit
by preferring the 0xc7 opcode for im32->reg64, instead of the
im64->reg64 form (which we therefore hardcode).
Traditional behaviour on x86-64 is to encode the relocation
addend in r_addend, not in the relocated field (after all,
that's the reason to use RELA relocs to begin with). Our
linker can deal with both, other linkers as well. But using
e.g. the GNU assembler one can detect differences (equivalent
code in the end, but still a difference).
Now there's only a trivial difference in tests/asmtest.S
(having to do with ordering of prefixes).
A bag of assembler fixes, to be either compatible with GAS
(e.g. order of 'test' operands), accept more instructions,
count correct foo{bwlq} variants on x86_64, fix modrm/sib bytes
on x86_64 to not use %rip relative addressing mode, to not use
invalid insns in tests/asmtest.S for x86_64.
Result is that now output of GAS and of tcc on tests/asmtest.S
is mostly the same.
Various x86 asm fixes: 64bit lcall/ljmp like 32bit a commit before,
xchgw accepted wrong operands on 32 and 64bit, and 64bit used
0x40/0x48+reg for incw/decw, but those are REX prefixes, not
instructions.
the check on incomplete struct/union/enum types was too early,
disallowing mixed specifiers and qualifiers. Simply rely on
the size (->c) field for that. See testcases.
The introduction of read32le everywhere created a subtle issue, going
from
x = *(int*)p;
to
x = read32le(p);
is not equivalent if x is a larger than 32bit quantity, like an
address on x86_64, because read32le returns an unsigned int. The first
sign extends, the latter zero extends. This broke shared library
creation for gawk. It's enough to amend the case of the above
situation, cases like "write32le(p, read32le(p) +- something)" are okay,
no extensions happen or matter.
R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX can occur in object files
comiled by new binutils. They are not dynamic relocations, so normally
wouldn't be a problem for tcc (one doesn't normally mix object files
created by different compiler/binutils, static archives are so out :)).
If it weren't for the glibc startup code, crt*.o, of course. They now
do contain such relocs --> boom. Handle them in the trivial way.
Some structs are passed in registers. When they need more than
one the implementation of __va_arg on x86-64 didn't correctly account
for this. This fixes only the cases where the structs consist of
integer types, as there the register save area is consecutive.
Fixes some tests from 73_arm64.c, but still leaves those failing
that use floating point in the large-but-regpassed structs.
The common code to move a returned structure packed into
registers into memory on the caller side didn't take the
register size into account when allocating local storage,
so sometimes that lead to stack overwrites (e.g. in 73_arm64.c),
on x86_64. This fixes it by generally making gfunc_sret also return
the register size.
This adds some more support for properly transfering some
offsets over the different stages of a relocations life.
Still not at all psABI compliant and DSOs can't yet be generated.
But it runs the testsuite in qemu-arm64.
This adds parsing of (GCC compatible) visibility attribute
in order to mark selected global symbols as hidden. The generated
.o files contain hidden symbols already, the TCC linker doesn't
yet do the right thing.
For conformance to ISO C the stdbool.h header has to provide
the macro __bool_true_false_are_defined (defined to 1). Yep,
that name is really in the standard.
Same as with x86_64, disable the runtime_plt_and_got hack
for -run on arm as well. For that we need to handle several
relocations as (potentially) generating PLT slots as well.
Tested with mpfr-3.1.2 and gawk (both using --disable-shared),
there are two resp. five pre-existing problems, so no regressions.
This also works toward enabling real shared libs for arm,
but it's not there yet.
This makes us use the normal PLT/GOT codepaths also for -run,
which formerly used an on-the-side blob for the jump tables.
For x86_64 only for now, arm coming up.
This provides a simple implementation of alloca for ARM (and enables
the associated testcase). As tcc for ARM doesn't contain an assembler,
we'll have to resort using gcc for compiling it.
These relocations are used to express a dependency on a certain
symbol (e.g. for EABIs exception handling to the
__aeabi_unwind_cpp_pr{0,1,2} routines). Just ignore them in
reloc processing.
When output is memory we applied the correct GOT offset for certain
relocations (e.g. _GOT32), but we forgot to actually fill the got
entries with the final symbol values, so unconditionally create relocs
against .got as well.
This makes it so that the first PT_LOAD segment covers
ELF and program header and .interp (contained in the same page anyway,
right before the start of the first loaded section). binutils
strip creates invalid output otherwise (which strictly is a binutils
bug, but let's be nice anyway).
This correctly resolves local references to global functions from
shared libs to their PLT slot (instead of directly to the target
symbol), so that interposition works.
This is still not 100% conforming (executables don't export symbols
that are also defined in linked shared libs, as they must), but
normal shared lib situations work.
negate(x) is subtract(-0,x), not subtract(+0,x), which makes
a difference with signed zeros. Also +x was expressed as x+0,
in order for the integer promotions to happen, but also mangles signed
zeros, so just don't do that with floating types.
Applying 64bit relocs assumes that the CVal is initialized to zero
for the whole 64bit. Consolidate this a bit, at the same time
zeroing the .ull member more consistently when needed. Fixes segfault
on x86_64-linux using global vars in tcctest.c.
Loads of VT_LLOCAL values (which effectively represent saved
addresses of lvalues) were done in VT_INT type, loosing the upper
32 bits. Needs to be done in VT_PTR type.
TCCs make dependency generator is incompatible with the GNU
depcomp script which is widely used. For TCC it has to go over
the output of -MD, (it detects it as ICC compatible), but the
sed commands it uses are confused by tabs in the output, so that
some rewrites aren't done.
Those tabs will then finally confuse make itself when the
generated .d files are included. It reads them as goal commands
(leading tab), and is totally lost then.
Short of changing depcomp (hard because distributed with all kinds
of software), simply emit spaces for -MD.
Sometimes the result of a comparison is not directly used in a jump,
but in arithmetic or further comparisons. If those further things
do a vswap() with the VT_CMP as current top, and then generate
instructions for the new top, this most probably destroys the flags
(e.g. if it's a bitfield load like in the example).
vswap() must do the same like vsetc() and not allow VT_CMP vtops
to be moved down.
This matters when sizeof is directly used in arithmetic,
ala "uintptr_t t; t &= -sizeof(long)" (for alignment). When sizeof
isn't size_t (as it's specified to be) this masking will truncate
the high bits of the uintptr_t object (if uintptr_t is larger than
uint).
This needs to be accepted:
typedef int foo;
void f (void) { foo: return; }
namespaces for labels and types are different. The problem is that
the block parser always tries to find a decl first and that routine
doesn't peek enough to detect this case. Needs some adjustments
to unget_tok() so that we can call it even when we already called
it once, but next() didn't come around restoring the buffer yet.
(It lazily does so not when the buffer becomes empty, but rather
when the next call detects that the buffer is empty, i.e. it requires
two next() calls until the unget buffer gets switched back).
When offsetted addresses of global non-static data are computed
multiple times in the same statement the x86_64 backend uses
gen_gotpcrel with offset, which implements an add insn on the
register given. load() uses the R member of the to-be-loaded
value, which doesn't yet have a reg assigned in all cases.
So use the register we're supposed to load the value into as
that register.
The first loop setting up struct arguments must not remove
elements from the vstack (via vtop--), as gen_reg needs them to
potentially evict some argument still held in registers to stack.
Swapping the arg in question to top (and back to its place) also
simplifies the vstore call itself, as not funny save/restore
or some "non-existing" stack elements need to be done.
Generally for a stack a vop-- operation conceptually clobbers
that element, so further references to it aren't allowed anymore.
Removes a premature optimization of char/short loads
rewriting the source type. It did so also for bitfield
loads, thereby removing all the shifts/maskings.
(cond ? 0 : ptr)->member wasn't handled correctly. If one arm
is a null pointer constant (which also can be a pointer) the result
type is that of the other arm.
Michael Matz