[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (E)GLIBC: inline syscalls



On Mon, Jun 22, 2009 at 10:19:05AM +0200, Petr Salinger wrote:
>>> INTERNAL_SYSCALL_close(name, err, nr, fd)
>>> INTERNAL_SYSCALL_writev(name, err, nr, fd, iov, cnt)
>>>
>>> Testsuite is OK, code is in glibc-bsd and pkg-glibc SVNs.
>
>> However I still think we should plan using real inline syscalls sooner
>> or later to avoid future problems like this one, but at least now we
>> have a bit of time.
>
> Unfortunately, we have to distinguish between kfreebsd-amd64 and  
> kfreebsd-i386 for this.
>
> For kfreebsd-amd64 it seems technically doable,
> performance lost or benefit should be minimal.
> The restriction is for syscalls with at most 6 arguments (almost all)
> and not for special syscalls - like pipe and fork.

Agreed. We can also easily pass the 7th argument on the stack, with very
few more instructions (3 if I am right).

> The kfreebsd-i386 case is much harder. There is even problem with  
> knowledge how many bytes should pe passed. There are syscalls accepting  
> 64-bit numbers even if it is declared as 1 argument.
> It is not possible to know whether an argument is 32-bits or 64-bits.
> We cannot infer it from variable size, as it might be incorect, even an  
> constant can be passed - examples are lseek, mmap, pread/pwrite.

This should be handled as on Linux, that is having too versions of the
code, the 32-bit in the main directory (possibly passing two 32-bit
values if needed), and the 64-bit version in the wordsize-64 directory,
with x86_64 implying wordsize-64.

> There will be also significant slowdown, as we have to prepare aguments  
> on stack, alter stack to get exactly the same stack layout as the 
> standard
> syscall would be used. We will lose correct unwinding info, et cetera,
> et cetera.

After some discussions on IRC, it seems the easiest way do to it, is to
fill all the arguments in a table, replace %esp by the address of
this table in the asm inline code, and restore the old value just after
the syscall.

For a small number of arguments (2 or 3), we could even directly setup
the stack in the asm inline code, passing those values through registers.

This clearly adds some more instructions, but that should be negligible
compared to the syscall itself which involves a context switch.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: