At early days we've been using only a few syscalls
which together with debug compiler options always
produce relative addresses for memory variables used
in parasite and restorer blobs. Thus it came in unnoticed
that there is something worng with syscalls declarations
we use.

Basically all our syscalls are just a wrappers over inline
assembly code in form of

static long syscall2(int nr, long arg0, long arg1)
{
	long ret;
	asm volatile(
		"movl %1, %%eax		\t\n"
		"movq %2, %%rdi		\t\n"
		"movq %3, %%rsi		\t\n"
		"syscall		\t\n"
		"movq %%rax, %0		\t\n"
		: "=r"(ret)
		: "g" ((int)nr), "g" (arg0), "g" (arg1)
		: "rax", "rdi", "rsi", "memory");
	return ret;
}

so every argument treated to be plain long (even if the call
sematics implies it's a memory address passed but not some
integer direct value) and transferred via general purpose
register.

As being mentioned it caused no problems when debug options
specified at compile time, the compiler do not tries to optimize
addressing but generates code which always compute them.

The situation is changed if one is building crtools with
optimization enabled -- the compiler finds that arguments
are rather plain long numbers and might pass direct addresses
of variables, instead of generating relative addresses
(because function declarations have no pointers and 'g' in cope
 with 'mov' is used, which is of course wrong).

To fix all this -- now syscalls declarations are generated from
syscall.def file and function arguments are passed in conform
with x86-64 ABI.

This shrinks amount of source code needed to declare syscalls
and opens a way to use optimization.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>