Re: (E)GLIBC: inline syscalls
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.
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.
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,
BTW, the fix for #531950 attr: FTBFS on GNU/kFreeBSD, have been applied upstream
May be there is a time for porter NMU, in the past two years, package have
been uploaded only by one of the uploaders, both are listed in LowThresholdNmu.