summaryrefslogtreecommitdiff
path: root/arch/i386/syscall_arch.h
AgeCommit message (Collapse)AuthorLines
2019-05-11improve i386 inline syscall asm on non-broken compilersRich Felker-1/+20
we have to avoid using ebx unconditionally in asm constraints for i386, because gcc 3 and 4 and possibly other simplistic compilers (pcc?) implement PIC via making ebx a fixed-use register, and disallow its use for anything else. rather than hard-coding knowledge of which compilers work (at least gcc 5+ and clang), perform a configure test; this should give us the good codegen on any new compilers we don't yet know about. swapping ebx and edx is kept for 1- and 2-arg syscalls because it avoids having any spills/stack-frame at all in small functions. for 6-arg, if ebx is directly usable, the complex shuffling introduced in commit c8798ef974d21c338a7d8d874a402978ffc6168e can be avoided, and ebp can be loaded the same way ebx is in 5-arg syscalls for compilers that don't support direct use of ebx.
2019-05-10fix regression in i386 inline syscall asm producing invalid codeRich Felker-6/+6
commit 22e5bbd0deadcbd767864bd714e890b70e1fe1df inlined the i386 syscall mechanism, but wrongly assumed memory operands to the 5- and 6-argument syscall asm would be esp-based. however, nothing in the constraints prevented them from being ebx- or ebp-based, and in those cases, ebx and ebp could be clobbered before use of the memory operand was complete. in the 6-argument case, this prevented restoration of the original register values before the end of the asm block, breaking the asm contract since ebx and ebp are not marked as clobbered. (they can't be, because lots of compilers don't accept these registers in constraints or clobbers if PIC or frame pointer is enabled). doing this right is complicated by the fact that, after a single push, no operands which might be memory operands are usable. if they are esp-based, the value of esp has changed, rendering them invalid. introduce some new dances to load the registers. for the 5-arg case, push the operand that may be a memory operand first, and after that, it doesn't matter if the operand is invalid, since we'll just use the newly pushed value. for the 6-arg case, we need to put both operands in memory to begin with, like the old non-inline code prior to commit 22e5bbd0deadcbd767864bd714e890b70e1fe1df accepted, so that there's only one potentially memory-based operand to the asm. this can then be saved with a single push, and after that the values can be read off into the registers they're needed in. there's some size overhead, but still a lot less execution overhead than the old out-of-line code. doing it better depends on a modern compiler that lets you use ebx and ebp in asm constraints without restriction. the failure modes on compilers where this doesn't work are inconsistent and dangerous (on at least some gcc versions 4.x and earlier, wrong codegen!), so this is a delicate matter. it can be addressed later if needed.
2019-04-10overhaul i386 syscall mechanism not to depend on external asm sourceRich Felker-9/+20
this is the first part of a series of patches intended to make __syscall fully self-contained in the object file produced using syscall.h, which will make it possible for crt1 code to perform syscalls. the (confusingly named) i386 __vsyscall mechanism, which this commit removes, was introduced before the presence of a valid thread pointer was mandatory; back then the thread pointer was setup lazily only if threads were used. the intent was to be able to perform syscalls using the kernel's fast entry point in the VDSO, which can use the sysenter (Intel) or syscall (AMD) instruction instead of int $128, but without inlining an access to the __syscall global at the point of each syscall, which would incur a significant size cost from PIC setup everywhere. the mechanism also shuffled registers/calling convention around to avoid spills of call-saved registers, and to avoid allocating ebx or ebp via asm constraints, since there are plenty of broken-but-supported compiler versions which are incapable of allocating ebx with -fPIC or ebp with -fno-omit-frame-pointer. the new mechanism preserves the properties of avoiding spills and avoiding allocation of ebx/ebp in constraints, but does it inline, using some fairly simple register shuffling, and uses a field of the thread structure rather than global data for the vdso-provided syscall code address. for now, the external __syscall function is refactored not to use the old __vsyscall so it can be kept, but the intent is to remove it too.
2016-01-26change the internal socketcall selection logicSzabolcs Nagy-0/+2
only use SYS_socketcall if SYSCALL_USE_SOCKETCALL is defined internally, otherwise use direct syscalls. this commit does not change the current behaviour, it is preparation for adding direct syscall numbers for i386.
2015-04-14use hidden visibility for i386 asm-internal __vsyscall symbolRich Felker-7/+7
otherwise the call instruction in the inline syscall asm results in textrels without ld-time binding.
2014-06-06add vdso clock_gettime acceleration support to i386Rich Felker-0/+4
2014-04-17make socketcall types common as they are same for all architecturesTimo Teräs-22/+0
2013-03-26remove __SYSCALL_SSLEN arch macro in favor of using public _NSIGRich Felker-2/+0
the issue at hand is that many syscalls require as an argument the kernel-ABI size of sigset_t, intended to allow the kernel to switch to a larger sigset_t in the future. previously, each arch was defining this size in syscall_arch.h, which was redundant with the definition of _NSIG in bits/signal.h. as it's used in some not-quite-portable application code as well, _NSIG is much more likely to be recognized and understood immediately by someone reading the code, and it's also shorter and less cluttered. note that _NSIG is actually 65/129, not 64/128, but the division takes care of throwing away the off-by-one part.
2012-10-13ensure pointer decay in inline-asm arg for i386 syscall6Rich Felker-1/+1
this is actually a rather subtle issue: do arrays decay to pointers when used as inline asm args? gcc says yes, but currently pcc says no. hopefully this discrepency in pcc will be fixed, but since the behavior is not clearly defined anywhere I can find, I'm using an explicit operation to cause the decay to occur.
2012-10-11i386 vsyscall support (vdso-provided sysenter/syscall instruction based)Rich Felker-66/+7
this doubles the performance of the fastest syscalls on the atom I tested it on; improvement is reportedly much more dramatic on worst-case cpus. cannot be used for cancellable syscalls.
2012-09-08syscall organization overhaulRich Felker-0/+136
now public syscall.h only exposes __NR_* and SYS_* constants and the variadic syscall function. no macros or inline functions, no __syscall_ret or other internal details, no 16-/32-bit legacy syscall renaming, etc. this logic has all been moved to src/internal/syscall.h with the arch-specific parts in arch/$(ARCH)/syscall_arch.h, and the amount of arch-specific stuff has been reduced to a minimum. changes still need to be reviewed/double-checked. minimal testing on i386 and mips has already been performed.