The problem was with tcctest.c:
unsigned set;
__asm__("btsl %1,%0" : "=m"(set) : "Ir"(20) : "cc");
when with tcc compiled with the HAVE_SELINUX option, run with
tcc -run, it would use large addresses far beyond the 32bits
range when tcc did not use the pc-relative mode for accessing
'set' in global data memory. In fact the assembler did not
know about %rip at all.
Changes:
- memory operands use (%rax) not (%eax)
- conversion from VT_LLOCAL: use type VT_PTR
- support 'k' modifier
- support %rip register
- support X(%rip) pc-relative addresses
The test in tcctest.c is from Michael Matz.
With -b, this produces garbage. Code to call __bound_local_new
is put at wrong place, overwriting the regparam setup code.
Fix copied from x86_64-gen.c.
void __attribute__((regparm(3)))
fun(int unused)
{
char local[1];
}
- call RtlDeleteFunctionTable
(important for multiple compilations)
- the RUNTIME_FUNCTION* is now at the beginning of the
runtime memory. Therefor when tcc_relocate is called
with user memory, this should be done manually before
it is free'd:
RtlDeleteFunctionTable(*(void**)user_mem);
[ free(user_mem); ]
- x86_64-gen.c: expand char/short return values to int
FreeBSDs system headers contain unconditional usage of
macros like __aligned(x), which are only conditionally defined
in sys/cdefs.h (conditional on __GNUC__ or __INTEL_COMPILER).
Bug in FreeBSD, but as work-around we can define __GNUC__ which
picks up these defs.
[This also moves back the glibc defines we had before into the
non-BSD ifdef branch]
With the last improvements to lexpand it's now harmful
to use on native 64bit platforms when not necessary. For gv_dup
it's not necessary there. It can still be used with really
transforming a 64bit value into two 32bit ones.
Previously, long longs were 'lexpand'ed into two registers
always.
Now, it expands
- constants into two constants (lo-part, hi-part)
- variables into two lvalues with offset+4 for the hi-part.
This makes long long operations look a bit nicer.
Also: don't apply i386 'inc/dec' optimization if carry
generation is wanted.
gen_cast() failed to truncate long long's if they
were unsigned, which was causing mess on the vstack.
There was a similar bug here
tccgen: 32bits: fix PTR +/- long long
ed15cddacd
Both were not visible until this patch
tccgen: arm/i386: save_reg_upstack
b691585785
I'd still assume that this patch is correct per se.
Also:
- remove 2x !nocode_wanted (we are already under a general
"else if (!nocode_wanted)" clause above).
__GNUC__ nowadays as macro seems to mean the "GNU C dialect"
rather than the compiler itself. See also
http://gcc.gnu.org/ml/gcc/2008-07/msg00026.html
This patch will probably cause problems of various kinds but
maybe we should try nonetheless.
With -run the call instruction and a defined function can be
far away, if the function is defined in the executable itself,
not in the to be compiled code. So we always need PLT slots
for -run, not just for undefined symbols.
Previously in order to perform a ll+ll operation tcc
was trying to 'lexpand' PTR in gen_opl which did
not work well. The case:
int printf(const char *, ...);
char t[] = "012345678";
int main(void)
{
char *data = t;
unsigned long long r = 4;
unsigned a = 5;
unsigned long long b = 12;
*(unsigned*)(data + r) += a - b;
printf("data %s\n", data);
return 0;
}
This is a work-around for TCC's linker, on AArch64, not building a PLT
when TCC is invoked with "-run". Fixing the linker should be possible:
it works on arm and x86_64, apparently.
The back end functions gen_op(comparison) and gtst() might allocate
registers so case_reg should be left on the value stack while they
are called and set again afterwards.
This bug fix was first applied as ff3f9aa (20 Feb 2015), but the fix
was reverted by fc0fc6a (21 Sep 2016, "switch: collect case ranges
first, then generate code"). Here the fix is updated for the new code.
- There's no need to force STRIP_BINARIES on windows since --enable-strip (at
configure) already does exactly that, if one wants to.
- Use the contigured $STRIP instead of the native 'strip', useful when
cross building tcc.
- 'make install-strip' now also strips libtcc.dll on windows (it already does
so now with --enable-strip, and previously it always stripped it).
Summary of current strip options for all platforms:
- configure --enable strip -> 'install -s' for the binaries.
- make install-strip: installs and then configured $STRIP the binaries.
- Otherwise -> no stripping.
MSYS2 installs 3 environments, with uname (e.g. on win8.1 64) as follows:
- MINGW32_NT-6.3 gcc -> stand-alone native i686 binaries
- MINGW64_NT-6.3 gcc -> stand-alone native x86_64 binaries
- MSYS_NT-6.3 gcc -> posix-ish binaries which can only run in this env
Therefore 'MINGW' is more generic and detects both 32/64 native
environments, where previously 'MINGW32' detected only the 32 one.
For the following reasons:
- Native windows links are rarely used in general.
- Require elevated privileges even if the current user has administrator
privileges (needs further "run as administrator").
- Most/all windows shell environments capable of running configure already
support ln (msys[1], msys2, most probably cygwin too).
- If cross building tcc on linux for windows then native mklink is not
available, as well as 'cmd' (in this scenario the build later fails
for other reasons, but at least configures succeeds now).
- cp is good enough as fallback since we only copy 5 makefiles anyway.
- The only environment I'm aware of which doesn't support ln -s is busybox
for windows, and with this patch it falls back to cp and completes
configure successfully (and the build later succeeds, assuming valid
$CC and $AR).
Also:
- regenerate all tests/pp/*.expect with gcc
- test "insert one space" feature
- test "0x1E-1" in asm mode case
- PARSE_FLAG_SPACES: ignore \f\v\r better
- tcc.h: move some things
We need to preserve the type of the pointer to the structure, f.ex.
when a global structure is returned.
This is not a perfect solution. Registers loaded in the first iteration
might be overwritten in a following iteration as the register is no
longer on vtop. This is not a problem for ARM32 as gfunc_sret returns
a maximum of 1 in the integer case.
