so it isn't quadratic in number of symbols. It's still quadratic
in number of lib/version combinations (at library load time the
sym versions are internalized), but that's much less a problem as
in practice only glibc uses sym versioning.
This fixes the issue
int main() { extern char *x; }
void main1() { extern char *x; }
t2.c:5: error: incompatible types for redefinition of 'x'
(reported by Giovanni Mascellani 2019/07/16)
Fedora, RHEL and Centos have a default page size of 64K for arm64, so
bump up the page size so that ELF sections of the generated inary are
correctly aligned for 64K pages too.
this fixes the ret_mixed_test of abitest.c, now everything of the
testsuite works.
The generic code for returns is good enough for our use, except in
the specific case of a mixed int/float structures returned in registers,
so instead of duplicating the whole generic gfunc_return function, add
another modus for gfunc_sret: returning -1 makes the actual register
transfer by a new backend function.
relocs against defined symbols are replaced by relative
relocs, when a GOT slot is created. But code relocs (usually
calls via PLT) use the plt_offset member of attr, not the got_offset
member, so the "huh" warning was triggered in the case of calls to
static functions (the code still worked).
So, for now just use the AUTO_GOT_PLT mechanism. We could also
emit a non-PLT reloc in the backend for calls to VT_STATIC functions
(like the x86-64 backend does) and do the same as for x86-64 in
build_got_entries (which transforms PLT32 into PC32 relocs, riscv
would transform CALL_PLT into CALL relocs). Maybe later.
this fixes ret_2float_test, ret_2double_test and
ret_8plus2double_test of abitest.c. The common gfunc_return
actually works for these cases, so let's use that for now.
The ret_mixed_test (as well as mixed2 and mixed3) are left
broken, and tccgen.c:gfunc_return can't be used for that as is,
so I'll leave the gfunc_return implementation in riscv64-gen.c for
now, I'll have to think about this some more.
this is it! With this tcctest.c works, as well as compiling
TCC with itself. abitest.c doesn't yet work due to known
problems, all the rest does. There are still warnings during
linking.
float to int must be truncations, not normal rounding.
And ftof was typoed to select the wrong conversion function.
This fixes tcctest.c completely. (make -C tests test1)
loads and stores to global symbols need to go via the
GOT (at least for weaks), otherwise -run doesn't work.
Ideally we'd generate GOT relocs (and loads) always and replace
them with PCREL relocs and adds during linking.
the invariant for the risc-v codegen is, that 64bit regs
generally contain the sign-extension of a 32bit value.
This wasn't heeded by loads of 32bit values from memory, which
used lwu and ultimately caused a miscompilation in string_test
of tcctest.c.
Now most of tcctest.c works (not with -run, but with linking
a real executable), except some ftoi/ftof conversions.
for the implementation of operations we can reuse the ones
from lib/lib-arm64.c, risc-v long double is also float128.
Also implement ggoto, and PDIV, and use t0 in load/store as
temporary register if necessary, not one given by get_reg
(the latter can destroy assignments of long double parameters
in function calls that are already set up).
This let's us compile tcc.c and tcctest.c, though both
don't yet work.
some constants were loaded wrong (e.g. 0xffffabcdU), and
risc-v needs to do explicit zero-extensions for widening from
32bit (not sign-extensions like the other 64bit targets).
This makes the whole tests2.all testsuite work.
Parameter passing is still not psABI-compliant, but internally
consistent. (e.g. structs of two floats/doubles are passed
in integer registers, but should sit in float regs).
this also fixes passing of params > 16 bytes. In riscv
they aren't passed by value on stack, but via reference (and
because callees are allowed to modify by-ref params the caller must
allocate an own copy per call).
This fixes the stdarg parts of 73_arm.c.
like long double (16 bytes) and structs. Not completely
correct, but 73_arm64 somewhat works now (when the stdarg part
is disabled), though with some errors. What's definitely incorrect
is arguments of a mixed int/float struct. I'm using VT_LDOUBLE
(which conveniently has to be placed in a int-reg-pair) to load/store
structure arguments of size > 8 and <= 16, and that can lead to
overreads.
for 101_cleanup we need 256kb stack (with the associated problem
of needing a larger prologue/epilogue) as well as jumps out of
range for the 21bit offsets (exactly for second part of the prologue).
