EABI functions to convert an int to a double register take the integer
value in core registers and also give the result in core registers.
It is thus necessary to move the result back to VFP register after the
function call. This only affected integer to double conversion because
integer to float conversion used a VFP instruction to do the conversion
and this obviously left the result in VFP register. Note that the
behavior is left untouched for !EABI as the correct behavior in this
case is unknown to the author of this patch.
- Thanks to Kirill "tcc -b itself" should work now
(was removed in d5f4df09ff)
Also:
- tests/Makefile:
- fix spurious --I from 767410b875
- lookup boundtest.c via VPATH (for out-of-tree build)
- test[123]b?: fail on diff error
- Windows: test3 now works (from e31579b076)
- abitest: a libtcc.a made by gcc is not usable for tcc
on WIndows - using source instead (libtcc.c)
- tccpe:
- avoid gcc warning (x86_64)
On my x86_64 box in i386 mode with address space randomization turned off,
I've observed the following:
tests$ ../tcc -B.. -b -run boundtest.c 1
Runtime error: dereferencing invalid pointer
boundtest.c:222: at 0x808da73 main()
With diagnostic patch (like in efd9d92b "lib/bcheck: Don't assume heap
goes right after bss") and bcheck traces for __bound_new_region,
__bound_ptr_indir, etc... here is how the program run looks like:
>>> TCC
etext: 0x8067ed8
edata: 0x807321d
end: 0x807d95c
brk: 0x807e000
stack: 0xffffd0b4
&errno: 0xf7dbd688
mark_invalid 0xfff80000 - (nil)
mark_invalid 0x80fa000 - 0x100fa000
new 808fdb0 808ff40 101 101 fd0 ff0
new 808ff44 808ff48 101 101 ff0 ff0
new 808ff49 8090049 101 101 ff0 1000
new 808fd20 808fd29 101 101 fd0 fd0
new 808fd2c 808fd6c 101 101 fd0 fd0
new 808fd6d 808fda0 101 101 fd0 fd0
E: __bound_ptr_indir4(0xffffd184, 0x4)
Runtime error: dereferencing invalid pointer
boundtest.c:222: at 0x808ea83 main()
So we are accessing something on stack, above stack entry for compiled
main. Investigating with gdb shows that this is argv:
tests$ gdb ../tcc
Reading symbols from /home/kirr/src/tools/tinycc/tcc...done.
(gdb) set args -B.. -b -run boundtest.c 1
(gdb) r
Starting program: /home/kirr/src/tools/tinycc/tests/../tcc -B.. -b -run boundtest.c 1
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
>>> TCC
etext: 0x8067ed8
edata: 0x807321d
end: 0x807d95c
brk: 0x807e000
stack: 0xffffd074
&errno: 0xf7dbd688
mark_invalid 0xfff80000 - (nil)
mark_invalid 0x80fa000 - 0x100fa000
new 808fdb0 808ff40 101 101 fd0 ff0
new 808ff44 808ff48 101 101 ff0 ff0
new 808ff49 8090049 101 101 ff0 1000
new 808fd20 808fd29 101 101 fd0 fd0
new 808fd2c 808fd6c 101 101 fd0 fd0
new 808fd6d 808fda0 101 101 fd0 fd0
E: __bound_ptr_indir4(0xffffd144, 0x4)
Program received signal SIGSEGV, Segmentation fault.
0x0808ea83 in ?? ()
(gdb) bt
#0 0x0808ea83 in ?? ()
#1 0x080639b3 in tcc_run (s1=s1@entry=0x807e008, argc=argc@entry=2, argv=argv@entry=0xffffd144) at tccrun.c:132
#2 0x080492b0 in main (argc=6, argv=0xffffd134) at tcc.c:346
(gdb) f 1
#1 0x080639b3 in tcc_run (s1=s1@entry=0x807e008, argc=argc@entry=2, argv=argv@entry=0xffffd144) at tccrun.c:132
132 ret = (*prog_main)(argc, argv);
132 ret = (*prog_main)(argc, argv);
(gdb) p argv
$1 = (char **) 0xffffd144
So before running compiled program, mark argv as valid region and we are
done - now the test passes.
P.S. maybe it would be better to just mark the whole vector kernel passes to
program (argv, env, auxv, etc...) as valid all at once...
when x86-64 support was added, "for long double, we use x87 FPU".
And indeed, tests show that Intel's extended precision is used,
not double precision.
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.
- Build libtcc1 for cross-compiler on arm (arm to X cross compilers)
- Install libtcc1 and includes for arm to i386 cross compiler
- Add basic check of cross-compilers (compile ex1.c)
Refactoring (no logical changes):
- use memcpy in tccgen.c:ieee_finite(double d)
- use union to store attribute flags in Sym
Makefile: "CFLAGS+=-fno-strict-aliasing" basically not necessary
anymore but I left it for now because gcc sometimes behaves
unexpectedly without.
Also:
- configure: back to mode 100755
- tcc.h: remove unused variables tdata/tbss_section
- x86_64-gen.c: adjust gfunc_sret for prototype
- tccgen: error out for cast to void, as in
void foo(void) { return 1; }
This avoids an assertion failure in x86_64-gen.c, also.
also fix tests2/03_struct.c accordingly
- Error: "memory full" - be more specific
- Makefiles: remove circular dependencies, lookup tcctest.c from VPATH
- tcc.h: cleanup lib, include, crt and libgcc search paths"
avoid duplication or trailing slashes with no CONFIG_MULTIARCHDIR
(as from 9382d6f1a0)
- tcc.h: remove ";{B}" from PE search path
in ce5e12c2f9 James Lyon wrote:
"... I'm not sure this is the right way to fix this problem."
And the answer is: No, please. (copying libtcc1.a for tests instead)
- win32/build_tcc.bat: do not move away a versioned file
Variants __fixsfdi/__fixxfdi are not needed for now because
the value is converted to double always.
Also:
- remove __tcc_fpinit for unix as it seems redundant by the
__setfpucw call in the startup code
- avoid reference to s->runtime_main in cross compilers
- configure: fix --with-libgcc help
- tcctok.h: cleanup
The procedure calling standard for ARM architecture mandate the use of
the base standard for variadic function. Therefore, hgen float aggregate
must be returned via stack when greater than 4 bytes and via core
registers else in case of variadic function.
This patch improve gfunc_sret() to take into account whether the
function is variadic or not and make use of gfunc_sret() return value to
determine whether to pass a structure via stack in gfunc_prolog(). It
also take advantage of knowing if a function is variadic or not move
float result value from VFP register to core register in gfunc_epilog().
Move the logic to do a test of an integer value (ex if (0)) out of
arch-specific code to tccgen.c to avoid code duplication. This also
fixes test of long long value which was only testing the bottom half of
such values on 32 bits architectures.
When statically linking, runtime library should be static as well. tcc
could link with libgcc.a but it's in a gcc version specific directory.
Another solution, followed by this patch, is to use libtcc.a when
statically linking, even if USE_LIBGCC was configured.
Use comisd / fcompp for float comparison (except TOK_EQ and TOK_NE)
instead of ucomisd / fucompp to detect NaN comparison.
Thanks Vincent Lefèvre for the bug report and for also giving the
solution.
Set *palign for VT_BITFIELD and VT_ARRAY types in classify_x86_64_arg as
else you happen to have in *palign what was already there. This can
cause gfunc_call on !PE systems to consider an array as 16 bytes align
and trigger the assert if the previous argument was 16 bytes aligned.
- avoid assumption "ret_align == register_size" which is
false for non-arm targets
- rename symbol "sret" to more descriptive "ret_nregs"
This fixes commit dcec8673f2
Also:
- remove multiple definitions in win32/include/math.h
- fix computation of absolute value (clearing the sign bit does not
since integers are encoded in 2's complement)
- test sign of integer in a more conventional way (binary and with the
high bit does not work for long long due to a bug in gtst)
- spacing in include
Add infrastructure to support special calling convention for runtime ABI
function no matter what is the current calling convention. This involve
2 changes:
- behave as per base standard in gfunc_call
- move result back in VFP register in gen_cvt_itof1
Thomas Preud'homme